[devel] rpm в p9

Leonid Krivoshein klark.devel на gmail.com
Сб Янв 19 20:21:23 MSK 2019


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-й уровень графа зависимостей исходного решения, гарантий это всё равно 
не даёт.

Другими словами, при нашей воспроизводимой сборке пакетов имеем 
непредсказуемую процедуру обновления установленных решений, в том числе, 
зависимую от времени обновления.


> с промежуточными межпакетными зависимостями вида
> ".${RPM_STRICT_INTERDEPS}-NEVR".
> [...]


-- 
Best regards,
Leonid Krivoshein.



Подробная информация о списке рассылки Devel