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

[Dmitriy M. Maslennikov]

25 сентября 2008 г. 13:22 пользователь Damir Shayhutdinov
<damir на altlinux.org> написал:
> Эта ситуация называется "смешивание репозитариев". Вы делаете эту
> операцию на свой страх и риск.
> Никаких гарантий на эту операцию никто дать не может.
Эта ситуация может быть вполне обычной, если второй репозиторий
специально приспособлен, чтобы быть подключенным к первому. Только в
альтах Сизиф очень не дружелюбен к сторонним репозитариям. Тогда как
дебиан вполне дружелюбен.

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

> Если вы имеете ввиду какие-то сторонние - то это все равно что в
> первый раз ставить. Из-за того, что лично вам это кажется нелогичным,
> вовсе не следует что во всем виноват апт или тем более рпм.
Ну вот хоть про нелогичность договорились.

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

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

>> Думайте шире. Пакет из Сизифа может быть переложен из этого самого
>> Сизифа в репозитарий имени Васи Пупкина. При этом запись о том, что в
>> такой то версии был поправлен такой то баг становиться вызывающе
>> неверной, так как пакет с этой версией в репозитарии Васи Пупкина
>> вообще такого бага не содержал.
> В таком случае это проблема Васи Пупкина. Предлагайте Пупкину выкинуть
> апт и рпм, потому что это инструмент плохой, а не Пупкин, который не
> предупредил своих пользователей о опасности смешивания репозитариев.
Эта опасность вам только кажется. В SuSe, как минимум ранше (а может и
теперь) в официальном репозитории лежала сборка libxine, которая при
попытке воспроизвести DVD, сообщала, что из-за лицензионных проблем
это невозможно, но если у вас в стране с этим спокойно, или вам вообще
плевать, то можно подключить сторонний репозиторий. Если его
подключить, то там лежит обычный libxine, который обновляет текущий,
плюс тащит libdvdcss, плюс еще пачку кодеков. В чем проблема. При этом
история у этих разных libxine все-таки должны быть разные. Вот вам и
привязка к репозиторию. При этом, если когда-нибудь проблемы с
лицензиями исчезнут, то при переносе сомнительной libxine в основной
репозиторий я бы хотел просто увидеть продолжение старой истории вида:
теперь с лицензиями все в порядке, поэтому мы переложили пакет из
кого-то репозитория в основной. Это полезная информация. А вот на
историю пакета в прошлом репозитории пользователям основного плевать,
поскольку ну не было у них его. Так вот и получается, что нет истории
пакета вообще, а только история пакета в репозитарии.

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

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

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

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

>> Тем не менее это все равно жуткий оверхед. Представьте, что вы
>> собираете игрушку уровня doom3 -- несколько гигабайт данных. И после
>> сборки заметили, что и вас один символ в %post скрипте не правильный
>> (опечатка), сильно вам поможит --short-circuit?
> Сильно поможет. Вы специально придумываете такие примеры?
Да не поможет, потому что пакет очень долго будет архивироваться.
Вместо этого нормальный пакет мог бы содержать дополнительную
информацию в конце файла и иметь средства при необходимости заменять
только ее.

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