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

[Damir Shayhutdinov]

> Эта ситуация может быть вполне обычной, если второй репозиторий
> специально приспособлен, чтобы быть подключенным к первому. Только в
> альтах Сизиф очень не дружелюбен к сторонним репозитариям. Тогда как
> дебиан вполне дружелюбен.
В любом случае это работа мантейнеров второго репозитария.
Центральный репозитарий в данном случае Сизиф (или бранч).

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

> Я знаю, что в Сизифе все в порядке. Но этот порядок там сейчас
> поддерживается вручную. Простая ситуация: мантейнер пакета foo уезжает
> в отпуск с ноутом в деревню без инета, где вылизывает новую версию
> этого пакета. За это время в пакете обнаруживают критическую багу и
> обновляют. Мантейнер возвращается и заливает свой пакет, не заметив
> обновления. Один changelog потерян.
Это проблема мантейнера - что он потерял NMU. В новой системе при
сборке из git такое будет исключено.

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

Правило изменения версий и релизов пакетов в Сизифе или в
дистрибутивах Альта вам известно. Вам надо лишь обеспечить чтобы ваши
собственные релизы не пересекались

Решение: использовать те же правила, что и для бекпортов.
Как один из вариантов - делайте версию -altN.maslM.

Сложно было догадаться?

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

>> Тогда это разные пакеты просто.
> Да но с одним названием из одних и тех же исходников...
Это ничего не значит. Важны не только исходники апстрима, но и патчи,
ключи configure,
версии компиляторов и много чего еще. Эта информация как правило
наследуется от предыдущих сборок. Поэтому changelog тут важен.

>> А если удалить драйвера nvidia (все равно они нерабочие)?
> Тоже вариант. Но потом вручную проверять не обновились ли они. А так
> как вышли бы новые, так автоматически и приехали бы и автоматика их бы
> поставила, мечты-мечты.
Напильник в руки, патчи в багзиллу.

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

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

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

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

> Да не поможет, потому что пакет очень долго будет архивироваться.
> Вместо этого нормальный пакет мог бы содержать дополнительную
> информацию в конце файла и иметь средства при необходимости заменять
> только ее.
Формат пакетов rpm открытый. Если бы такие возможности были
кому-нибудь нужны - давно бы уже написали программу для этого. Ищите.
Если нет - значит это нужно только вам.

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