[devel] поддержка пакетов в git

[Dmitriy M. Maslennikov]

25 сентября 2008 г. 19:31 пользователь Damir Shayhutdinov
<damir на altlinux.org> написал:
> Вы вкурсе, что если вы в репозитарии уберете пакет, он магическим
> образом у пользователей, которые его поставили, не исчезнет?
Конечно.

> Опишите что это за "внутренняя версия apt", как она создается, для
> чего и что делать если делается апгрейд
> с бранча на сизиф например? При том что в бранче бэкпорты как правило
> базируются на пакете в Сизифе, и как следствие, имеют более позднюю
> дату сборки?
Запросто. Я уже описывал это в этом треде, но, наверное он слишком велик.

Так вот перебирать кучу пакетов с помощью genbasedir - очень
неоптимальное действие. Его надо заменить на процедуру добавления
пакета.

При добавлении пакета foo, если такого еще не было ему присваивается
версия 1, если уже был, то она поднимается. Эта внутренняя версия к
версии rpm она отношения не имеет. При этом если пакет у нас уже был,
то для замены его новой версией (не в смысле rpm, а в смысле
внутренней версии) обязательно должен быть описано изменение, которое
производит это выкладывание. Из этих описаний формируется changelog.

Подключение репозитория (бранч, сизиф, вообще сторонний -- это не
важно) означает, что вы доверяете людям, которые ведут этот
репозитарий (при этом указывается приоритет репозитария, как степень
доверия). При указании обновить систему менеджер пакетов (apt), должен
найти в каких репозиториях находятся пакеты уже установленные в
системе и при необходимости заменить их на самые свежие из
соответствующих репозитариев.

Если пакет был найден в нескольких, то в рассмотрение берется самый
приоритетный, а остальные игнорируются.

Переход с бранча на сизиф при такой схеме осуществляется подключением
сизифа, как более приоритетного репозитария, что автоматически
означает, что все пакеты имеющиеся в нем будут доминировать и заменят
уже установленные.

>> С чего он будет даунгрейдить пакеты? Из чего это следует. Он будет
>> обеспечивать наличие у пользователя версий пакетов выложенных
>> последними. Сами версии значения не имеют. Раз мантейнер выложил
>> пакет, значит было надо.
> С вышеописанного (про внутреннюю версию апта).
Как видим, apt будет даунгрейдить пакет, только если он имеется в
более приоритетном репозитарии. Раз уж вы его поставили как более
приоритетный, то знали, что он будет управлять вашими пакетами. Если
вам необходима большая версия -- подключаем репозитарий, в котором она
есть как более приоритетный. Пакетам установленным вручную (не из
репозитария), так же назначается приоритет. Полезно уметь выводить
список таких пакетов, как и вообще списки пакетов, поставленных из
того или иного репозитария.

>> Я не всегда собираю пакет для того, чтобы отдать его конечному
>> пользователю. Я понимаю необходимость такого контроля при
>> выкладывании, скажем, в Сизиф, но я часто собираю пакет для себя на
>> потестить, или чтобы иметь возможность его дать тестеру и т. п. Баги в
>> таких пакетах совсем не так критичны, как легкость их создания.
> Очевидно, слова "воспроизводимость" для вас пустой звук. Вы тестируете
> бинарного коня в вакууме, собранного неизвестно из чего? Гм, ну тут я
> ничего сказать не могу. Жалко ваших тестировщиков.
На самом деле в 99% я бываю прав. Потери времени на оставшийся процент
многократно компенсируются гигантской экономией времени на
сборку/пересборку.

> git/gear не пробовали? Отличное решение для совместной разработки. А в
> вашем случае это именно совместная разработка, а не ведение
> репозитария. Сценарий взаимодействия другой.
Только ими и пользуюсь. Без них вообще бы труба. С чего вы все время
делаете вывод, что я не знаю ваш инструментарий?
Проблема в том, что часто надо отдать именно бинарную сборку. И кучу
файлов с ней. И если она не удачна, то дать возможность все удалить.
Поэтому надо собирать rpm, и на это тратиться много сил и времени,
хотя чаще всего пакет собирается только, чтобы продемонстрировать
мелкое изменение людям внутри компании, которое больше никуда не
пойдет. При таких задачах rpm очень сильно умничает. А вот apt тупит.

>> Вот именно. Я такие и не выкладываю, но это сильно ускоряет процесс
>> установки. После того, как он завершен, можно спокойно сделать пакет
>> начисто. И так делаю не только я -- это точно.
> Процесс установки чего? Фразу не понял.
Фразу надо читать как "просесс разработки". Опечатался я.

>>> Я всегда делаю контрольную "чистовую" пересборку после завершения
>> Я тоже так делаю, и что?
> Тогда я не вижу с чего вы в одном случае так делаете, а в другом вам
> почему-то этого делать не хочется.
Только потому, что один пакет идет пользователю, а второй собирается
для себя на посмотреть, через пять минут удаляется и продолжается
процесс разработки.

>> Эта автоматика нужна во время финальной сборки, перед публикацией, не
>> во время активной разработки.
> А потом вы жалуетесь что автоматика срабатывает слишком поздно, когда
> пакет уже собран. Надо определяться, чего именно хочется. Хочется
> правильной сборки - не отключайте проверку.
Автоматика с sisyphus_check и repocop очень нормальная и своевременная
и хорошо, что отключаемая. Хочется, чтобы уметь менять rpm без
пересборки. И без проверок. Ибо так иногда НАДО. Чтобы предупредить
всякие обвинения я заранее говорю, что поддерживаю то, что пакетам не
проходящим sisyphus_check в Сизифе не место. Но я еще раз говорю, что
пакеты бывают не только для Сизифа и остальных публичных репозиториев.

> да все обновляется, через rpm. Но вы ж должны понимать, что без смены
> релиза результат вашего дистрибутива можно ставить только вашим
> тестерам и более никому. Пока это между вами и тестером - пользуйтесь
> чем угодно. Но в люди выходить без смены релиза - засмеют.
rpm, да. А вот apt'ом -- нет.

Как бы это показать...
Вот пишу я библиотеку, а за соседним столом разработчик пишет
программу, которая ее использует. И вот он замечает баг, который ему
мешает. Он сообщает мне. Я быстро его исправляю, собираю новый пакет,
автоматом отправляю свою новую сборку во внутренний репозитарий, он
обновляется и мы продолжаем работу. При этом я рискую забыть поднять
версию (хотя зачем мне ее поднимать вообще?), забыть написать
changelog (хотя зачем -- этот пакет вообще просто недоразумение,
которого не должно было быть) и моного чего еще я рискую забыть.

А вот когда пройдет этап разработки, то конечно мы все соберем
начисто, все проверим всеми возможнымипроверками и отдадим
пользователям.

-- 
Dmitriy M. Maslennikov
rlz на etersoft.ru
rlz на altlinux.org
maslennikovdm на gmail.com
master на armory.ru