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

[Damir Shayhutdinov]

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

>> Решение: использовать те же правила, что и для бекпортов.
>> Как один из вариантов - делайте версию -altN.maslM.
> Есть задача: заменить один из пакетов в Сизифе. Как этого добиться не
> понимаю, разве что с помощью serial, но что если в Сизифе сериал
> поднимется выше моего?
У вас задача неполная. "Заменить один из пакетов в Сизифе" может на
практике означать несколько вариантов, как то - замена определенной
сборки пакета (release), замена определенной версии (на ту же или
большую), замена "навсегда".

Замена определенной сборки пакета делается просто. Допустим это была
сборка version-alt1. Делаете релиз alt1.masl1 - и все в порядке. При
этом если в Сизифе появится сборка с alt2 - то она перекроет вашу
местную сборку.

Замена определенной версии делается примерно также. То есть вы хотите
чтобы пакет из Сизифа версии M был заменен на ваш, а версии M+1 -
брался из Сизифа. Тогда делаете релиз равный alt999.masl1.

Замена "навсегда" - делаете пакет с Serial: сто-пятьсот-тысяч-мульенов.

Мне кажется что ваша позиция "апт и рпм плохие, а я самый умный" в
данном случае мешает вам находить эти очевиднейшие решения.

> Ну вышесказанное относилось к гипотетической возможности
> перекладывания пакетов между репозитариями вообще без пересборки.
Перечитайте контекст.


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

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

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

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

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

> Это вы должны вызывать rpmbuild с --short-circuit "при условии"
> выполнения предыдущих стадий, а вот он запускается "в надежде" на это.
> Кстати, я частенько менял исходники, а затем вызывал
>
> $rpmbuild -bc --short-circuit
>
> и мне плевать, что формально у меня -bi уже не выполнено. Зато после
> починки сборки я могу одним движением сделать diff.
После такого признания хочется посмотреть список ваших пакетов, чтобы
никогда их не ставить в систему. Сборки, которые не соответствуют
.src.rpm - нужны только вам.
Я всегда делаю контрольную "чистовую" пересборку после завершения
хаков с --short-circuit. И тестирую именно ее. Да, это дольше. Зато я
не трачу времени на поиск багов, которые я могу внести ковырясь с
--short-circuit.

> Наверное дело в том, что я больше не собираю пакеты, а разрабатываю их
> с нуля. Собираю соответственно в основном свои пакеты для того, чтобы
> отдать их на потестить. Качество самого пакета при этом не критично
> (до стадии выкладывания пользователю), так вот меня пересборка rpm на
> каждый чих уже совсем не радует (и давно). Меня достает, что каждый
> раз, когда я поправил мелкий баг (до 10-15 раз за день) собрал пакет,
> я вдруг осознаю, что люди его через apt не получат, поскольку
> версию-то я сменить забыл, а потом вдруг окажется, что забыл вписать
> changelog, вот так и пересобираешь все по сто раз.
Все ясно.

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

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