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

[Damir Shayhutdinov]

>>> В целом да, только я скорее имел в виду не возможность обновления до
>>> Сизифа, а именно репозиторий, как довесок к Сизифу, использующийся с
>>> ним совместно.
>> Гм. А тут тогда в чем проблема? Если это пакеты, которых в сизифе нет
>> - пересечений быть не должно.
> Я про пересечения пример с libxine приводил.
Второй или третий вариант.

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

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


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

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

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

> Представьте, что вам перед каждой компиляцией программы надо где-то в
> файле обязательно поднимать версию иначе версия не собирается, но не
> сразу, а ближе к финалу.
Ну если отключать автоматику на входе в хешер - то еще и не такое
можно получить. ССЗБ.

> Это кошмар! Публичные же релизы достаточно
> редки, их можно и повылизывать и тут всякие барьеры вида sisyphu_check
> repocop и прочее очень полезны. Но вот отсутствие инструментария для
> быстрых изменений...
sisyphus_check полезен всегда. А инструментарий отсутствует, на мой
взгляд, по стандартной причине опенсорса. Те, кому нужен
инструментарий, по очевидным причинам не могут его написать. А те кто
могут написать, по не менее очевидным причинам он не нужен.

>>> Отлично, пусть произойдет повторный поиск зависимостей по скриптам,
>>> зачем пересобирать?
>> rpm -bb --short-circuit делает то что надо в этом случае. Производит
>> повторный поиск зависимостей.
> Кроме этого он заново начнет архивировать файлы, а ведь мне надо было
> только информацию о пакете поправить.
Только такой способ позволяет удостовериться, что пакет получился
целостным, а не хакнутым руками с конечным радиусом кривизны через
конечного радиуса кривизны программу для правки информации о пакете.
Например, информация о версии и релизе пакета может быть использована
также в Requires/Provides пакетов и подпакетов. И если ее менять, это
надо делать везде, чтобы было целостное изменение.

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

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

> Вот-вот, ведешь разработку, радостно закоммитил мелкие изменения,
> запускаешь сборку и тут эта пакость (но ее я уже отключаю автоматом).
Ха-ха-ха. Вопрос об адекватности закрыт.

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

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