Re: [devel] rpm в p9

[Anton Farygin <rider@basealt.ru>]

19.01.2019 20:21, Leonid Krivoshein пишет:
>
> 19.01.2019 15:11, Dmitry V. Levin пишет:
>> On Sat, Jan 19, 2019 at 10:32:07AM +0300, Anton Farygin wrote:
>> [...]
>>> а довести rpm в Sisyphus
>>> до состояния, когда его можно будет полноценно использовать для работы.
>>>
>>> А в *8 ветках оставить как есть сейчас.
>> Как сейчас тоже нехорошо, потому что apt неисправимо плохо работает
>
> Посмотрев исходники APT'а (нашего и современного Дебиновского), могу 
> сказать, что здесь стоит поставить точку. Неисправимая ошибка в 
> дизайне. На dist-upgrade он непредсказуем из-за алгоритма весов и 
> приоритетов. У нас в RPM, ко всему прочему, поля приоритета просто 
> нет. Алгоритм разрешения конфликтов отлично справляется в пределах 
> одной частной машины, но если взять хотя бы две одинаковые машины с 
> полностью одинаковым набором пакетов и начать обновлять их в разное 
> время, то рано или поздно не только пакетные базы разойдутся, но и на 
> одной из них могут быть вынесены ключевые для исходного решения пакеты.
>
> Если сильно упростить: первоначальная установка системы -- это apt-get 
> install A B C (со всеми зависимостями, которые мы конечно не 
> указываем), тогда как apt-get dist-upgrade -- это отнюдь не повторение 
> этой операции, а игра в лотерею "мне повезёт". Но это чисто поворчать, 
> просто так это не исправить. Использование /etc/apt/pkgpriorities с 
> умом лишь уменьшает вероятность серьёзных разъездов и заставляет APT 
> хотя бы предупредить при выносе критически важных пакетов. Но это 
> укрепляет лишь 0-й уровень графа зависимостей исходного решения, 
> гарантий это всё равно не даёт.
>
> Другими словами, при нашей воспроизводимой сборке пакетов имеем 
> непредсказуемую процедуру обновления установленных решений, в том 
> числе, зависимую от времени обновления.

К воспроизводимости сборки тоже есть вопросы - в последнее время очень 
часто Beehive ругается тогда, когда локально проблема сборки не 
воспроизводится. К счастью, чаще всего это race в результате 
параллельной сборки.

А солвер в apt давно уже надо кому-то переписать, но для этого нужно 
поменять нашу пакетную базу - избавиться от виртуальных пакетов, 
например, что бы не было одинаковых provides у разных пакетов.