[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