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

Dmitriy M. Maslennikov =?iso-8859-1?q?maslennikovdm_=CE=C1_gmail=2Ecom?=
Чт Сен 25 15:21:11 MSD 2008


25 сентября 2008 г. 14:50 пользователь Damir Shayhutdinov
<damir на altlinux.org> написал:
> В любом случае это работа мантейнеров второго репозитария.
> Центральный репозитарий в данном случае Сизиф (или бранч).
>
> Лично я не вижу препятствий, из-за которых мантейнеры второго
> репозитария не могли бы поддерживать
> возможность обновления с их репозитария до Сизифа например по тем же
> правилам, по которым поддерживаются
> пакеты в бранчах.
В целом да, только я скорее имел в виду не возможность обновления до
Сизифа, а именно репозиторий, как довесок к Сизифу, использующийся с
ним совместно.

> Это проблема мантейнера - что он потерял NMU. В новой системе при
> сборке из git такое будет исключено.
Посмотрим :)

>> Чего это вдруг. Я собираю пакет для себя у себя. Кто-то еще у себя для
>> себя. А кто-то для Сизифа. Как нам синхронизироваться, через
>> libastral?
> Синхронизоваться надо если есть общий ресурс. Если общего ресурса нет
> - синхронизация не нужна.
> Общий ресурс в данном случае - версия + релиз.
>
> Правило изменения версий и релизов пакетов в Сизифе или в
> дистрибутивах Альта вам известно. Вам надо лишь обеспечить чтобы ваши
> собственные релизы не пересекались
>
> Решение: использовать те же правила, что и для бекпортов.
> Как один из вариантов - делайте версию -altN.maslM.
Есть задача: заменить один из пакетов в Сизифе. Как этого добиться не
понимаю, разве что с помощью serial, но что если в Сизифе сериал
поднимется выше моего?

>> плюс тащит libdvdcss, плюс еще пачку кодеков. В чем проблема. При этом
>> история у этих разных libxine все-таки должны быть разные.
> Не вижу никаких причин для вышеозвученного тезиса. Здесь у вас логика
> спотыкается и хромает.
> Поэтому все нижеследующие можно пропустить. Обоснуйте-ка этот тезис.
Ну вышесказанное относилось к гипотетической возможности
перекладывания пакетов между репозитариями вообще без пересборки.

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

>>, а вопрос "зачем пересобирать
>> пакет с нуля, если вся разница заключается в версии/описании/etc"
> Если вы например в скриптах post/postun исправили "опечатку", это
> может повлечь изменение зависимостей пакета. То есть как минимум после
> каждого изменения скриптов надо провести повторный поиск зависимостей.
Отлично, пусть произойдет повторный поиск зависимостей по скриптам,
зачем пересобирать?

>>> Гм. У вас тут фундаментальное непонимание чего делает --short-circuit.
>> Да ничего интересного он не делает. Просто выполняет одну стадию
>> сборки, пропуская все остальные в надежде, что они уже выполнены.
> При условии что они уже выполнены. Если вы меняете что-нибудь в спеке
> - это одно. А если в исходниках - это другое. В таком случае условие
> "они уже выполнены" не соблюдаются.
Это вы должны вызывать rpmbuild с --short-circuit "при условии"
выполнения предыдущих стадий, а вот он запускается "в надежде" на это.
Кстати, я частенько менял исходники, а затем вызывал

$rpmbuild -bc --short-circuit

и мне плевать, что формально у меня -bi уже не выполнено. Зато после
починки сборки я могу одним движением сделать diff.

> Пока получается, что ради того, чтобы "0.0001% пакетов не очень долго
> архивировался в случае, если допущена ошибка в дополнительной
> информации (ну допустим вероятность ошибки около 50%)", вы предлагаете
> решение, которое как минимум дольше и разрабатывать, и поддерживать.
> Если вам это так интересно и нужно - предлагаю взять в руки librpm и
> написать требуемую программу. 0.0001% мантейнеров в 50% случаев вам
> скажут большое спасибо.
Может быть вы и правы, но у меня другая оценка процентных соотношений.
Наверное дело в том, что я больше не собираю пакеты, а разрабатываю их
с нуля. Собираю соответственно в основном свои пакеты для того, чтобы
отдать их на потестить. Качество самого пакета при этом не критично
(до стадии выкладывания пользователю), так вот меня пересборка rpm на
каждый чих уже совсем не радует (и давно). Меня достает, что каждый
раз, когда я поправил мелкий баг (до 10-15 раз за день) собрал пакет,
я вдруг осознаю, что люди его через apt не получат, поскольку
версию-то я сменить забыл, а потом вдруг окажется, что забыл вписать
changelog, вот так и пересобираешь все по сто раз.

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


Подробная информация о списке рассылки Devel