[devel] Fwd: [sisyphus] Новая версия GnuPG в Сизифе

Vladimir D. Seleznev vseleznv на altlinux.org
Пт Окт 18 20:26:06 MSK 2019


On Fri, Oct 18, 2019 at 11:54:02AM +0300, Paul Wolneykien wrote:
> В Fri, 18 Oct 2019 03:33:23 +0300
> "Vladimir D. Seleznev" <vseleznv на altlinux.org> пишет:
> 
> > >   Вот Git, например, отлично себя чувствует, если ему передать
> > > gpg.program = /usr/bin/gpg2 , Claws-Mail --- тоже, Enigmail ---
> > > тоже. Подозреваю, что и Mutt способен адаптироваться без проблем.
> > > Кто же остаётся?
> > > 
> > >   Те же, кому очень важно именно gnupg1 вполне могут иметь
> > > "Requires: gnupg1", почему нет?  
> > 
> > Переименование пакетов — всегда рискованное занятие.  Невозможно
> > полностью спрогнозировать что в итоге пойдёт не так и может
> > сломаться. С другой стороны, никакой беды в том, что пакет называется
> > gnupg2 и содержит в себе номер версии, нет. Но я уже не в первый раз
> > сталкиваюсь с тем, что кто-то хочет переименовать какой-нибудь pkgN в
> > pkg. У этого есть разумное объяснение? В чём проблема наличие числа
> > (обычно мажорной версии) в имени пакета?
> 
>   Дело, естественно, не в названии пакета, а в его содержимом. Дело в
> необходимости перенастройки других программ на /usr/bin/gpg2 вместо
> /usr/bin/gpg. Было бы здорово, если бы это решалось установкой пакета.
> Для программ, предназначенных исключительно для GnuPG 1.x, остался бы
> /usr/bin/gpg1 (на который их нужно было бы явно заранее перевести).

Проблема в том, что программы, которым нужен первый gnupg, _уже зависят_
от /usr/bin/gpg.  В то же время те программы, которым нужен второй
gnupg, можно собирать с зависимостью на /usr/bin/gpg2 и настройкой на
него. Ты не можешь исправить у всех пользователей на всех уже
установленных системах /usr/bin/gpg на /usr/bin/gpg1, но ты можешь
собирать новые пакеты так, чтобы у них были правильно прописаны
зависимости на /usr/bin/gpg2. Это надёжнее в поддержке и обратно
совместимо с уже существующими установками, и не ломает точечные
обновления.

Надо понимать, что мы поддерживаем репозиторий, а это подразумевает
заботу об обратной совместимости, обновляемости систем без
непредсказуемых поломок поведения и поддержки точечных обновлений. Что
неизбежно приводит к накапливанию легаси и принципиальных решений
наподобие gnupg — это первая версия gnupg. Иначе это невозможно было бы
поддерживать. Если бы мы строили системы каждый раз заново, заново
бутстрапя и без подразумевания вообще никаких обновлений, это всё было
бы не принципиально, ведь каждый раз мы собирали новую систему.

Или надо было идти другим путём: не поддерживать репозиторий Сизиф, а
сделать, как например, Fedora: выпускать раз в полгода новую ветку
репозитория и поддерживать обновления только на соседние ветки, тогда
проще было бы устраивать революции. Но это совсем другой стиль работы и
поддержки репозиториев. И никаких живых систем на development-бранчах.

-- 
   С уважением,
   Владимир Селезнев


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