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

[Dmitriy M. Maslennikov]

25 сентября 2008 г. 16:13 пользователь Damir Shayhutdinov
<damir на altlinux.org> написал:
>> В целом да, только я скорее имел в виду не возможность обновления до
>> Сизифа, а именно репозиторий, как довесок к Сизифу, использующийся с
>> ним совместно.
> Гм. А тут тогда в чем проблема? Если это пакеты, которых в сизифе нет
> - пересечений быть не должно.
Я про пересечения пример с libxine приводил.

> У вас задача неполная. "Заменить один из пакетов в Сизифе" может на
> практике означать несколько вариантов, как то - замена определенной
> сборки пакета (release), замена определенной версии (на ту же или
> большую), замена "навсегда".
>
> Замена определенной сборки пакета делается просто. Допустим это была
> сборка version-alt1. Делаете релиз alt1.masl1 - и все в порядке. При
> этом если в Сизифе появится сборка с alt2 - то она перекроет вашу
> местную сборку.
>
> Замена определенной версии делается примерно также. То есть вы хотите
> чтобы пакет из Сизифа версии M был заменен на ваш, а версии M+1 -
> брался из Сизифа. Тогда делаете релиз равный alt999.masl1.
>
> Замена "навсегда" - делаете пакет с Serial: сто-пятьсот-тысяч-мульенов.
>
> Мне кажется что ваша позиция "апт и рпм плохие, а я самый умный" в
> данном случае мешает вам находить эти очевиднейшие решения.
Все вышеописанное я делал многократно. Просто у вас задач таких не
было. Например: подменить пакет в Сизифе с помощью стороннего
репозитария, а потом когда с тем пакетом все разногласия будут улажены
убрать свой. То есть я сам решаю, когда это случиться.

> Ключевое слово тут - _обновляет_.
> Вспоминаем изначальный вопрос: "Не понимаю, как пакеты установленные у
> пользователя мешают нормальной
> работе репозитория". Ответ такой - у пользователя версии установленные
> могут быть выше того, что лежит в репозитарии, и поэтому эти пакеты не
> будут обновлены (то есть заменены из репозитария).
> Таким образом, "откат версий" централизованно можно сделать только с
> изменением Serial. А изменение Serial:Version-Release - это новая
> строчка в changelog и новая сборка пакета.
Это только потому, что apt кривой. Точнее не кривой даже, а просто
когда задумывался, то в нем это не предусмотрели. Не вижу проблемы в
том, чтобы пакеты обновлялись не по rpm-версии, а по внутренней версии
apt. Тогда можно было бы выкладывать пакеты в любой последовательности
с гарантией, что пользователь получит последнюю выложенную версию. И
костыль с serial станет не нужным вообще.

> Отмечу, что нецентрализованный откат версий может делаться как с
> помощью прямого указания старой версии (apt-get install
> package=version), так и с помощью apt_preferences.
Нецентрализованный не интересен. Не надо напрягать пользователя, это
мы для него, а не он для нас.

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

> Я не могу спорить с человеком, который считает пересборку излишней при
> изменении версии пакета и добавлении записи в changelog. Вы такой
> хакер что можете предусмотреть все последствия этих изменений? Тогда
> пишите программу для этого. Я лично не берусь предусмотреть всех
> последствий, для чего делаю контрольную пересборку начисто.
Я не всегда собираю пакет для того, чтобы отдать его конечному
пользователю. Я понимаю необходимость такого контроля при
выкладывании, скажем, в Сизиф, но я часто собираю пакет для себя на
потестить, или чтобы иметь возможность его дать тестеру и т. п. Баги в
таких пакетах совсем не так критичны, как легкость их создания. Я
вообще не желаю в этом случае поднимать версию пакета, так как
незачем, иначе версии взлетять до тысяч... Я же их не публикую.
Представьте, что вам перед каждой компиляцией программы надо где-то в
файле обязательно поднимать версию иначе версия не собирается, но не
сразу, а ближе к финалу. Это кошмар! Публичные же релизы достаточно
редки, их можно и повылизывать и тут всякие барьеры вида sisyphu_check
repocop и прочее очень полезны. Но вот отсутствие инструментария для
быстрых изменений...

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

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

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

> Все ясно.
Ну наконец-то!

> У меня никогда не бывает что я "не вписал changelog" - просто на входе
> в хешер sisyphus_check такой пакет не пропустит. Да и забыть сменить
> версию тоже сложно - обычно тарбол апстримный разворачивается в
> %name-%version, а если %version не совпадает, то пакет даже не начнет
> собираться.
Вот-вот, ведешь разработку, радостно закоммитил мелкие изменения,
запускаешь сборку и тут эта пакость (но ее я уже отключаю автоматом).
Эта автоматика нужна во время финальной сборки, перед публикацией, не
во время активной разработки.

> Очевидно, что вы ваши сборки через sisyphus_check не гоняете. Советую
> приучиться это делать - тогда пересобирать по сто раз не придется.
> (это безотносительно к рекомендации пользоваться hasher).
К сожалению, sisyphus_check не проверяет поднял ли я версию пакета...
А потом у тестеров пакет не обновляется.

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