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

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

[Paul Wolneykien]

-------- Перенаправленное сообщение --------
Тема: [sisyphus] Новая версия GnuPG в Сизифе
Дата: Thu, 17 Oct 2019 15:50:53 +0300
От: Paul Wolneykien <manowar@altlinux.org>
Кому: ALT Linux Sisyphus mailing list <sisyphus@lists.altlinux.org>

> 
>   Здравствуйте. Вчера в Сизиф отправилась новая сборка GnuPG 2.2.17
> обновлёнными патчами для поддержки ГОСТ.
> 
>   Самое основное заключается в том, что появилась поддержка ГОСТ 2012.
> Однако в S/MIME (gpgsm) она по-прежнему ограничена необходимостью
> использовать смарт-карту или токен. А вот в режиме OpenPGP (gpg2) уже
> есть поддержка генерации ГОСТвых ключей и поэтому их можно использовать
> без аппаратной поддержки. Другое дело, что ГОСТ в OpenPGP пока никак не
> стандартизирован и данная реализация является чисто экспериментальной.
> 
>   Подробнее о недоработках и дальнейших планах:
> 
>   1. gpg2 --version и gpgsm --version не выводят информацию о поддержке
> ГОСТ, а надо бы;
> 
>   2. реализацией gpg по умолчанию у нас до сих пор является gpg1
> (1.4), не пора ли переехать на gpg2?

  Что будет, если я в пакете gnupg2 напишу "Provides: gnupg" ?


>   3. поддержка генерации ключей и сертификатов ГОСТ в gpgsm (это нужно в
> том числе и для автотестов);
> 
>   4. стандартизация ГОСТ в OpenPGP.

[devel] Provides: gnupg (Was: Новая версия GnuPG в Сизифе)

[Sergey V Turchin]

On Thursday, 17 October 2019 16:39:27 MSK Paul Wolneykien wrote:

[...]
> >   2. реализацией gpg по умолчанию у нас до сих пор является gpg1
> > 
> > (1.4), не пора ли переехать на gpg2?
> 
>   Что будет, если я в пакете gnupg2 напишу "Provides: gnupg" ?
Как минимум, не получится написать "Provides: /usr/bin/gpg", а
$ apt-cache whatdepends /usr/bin/gpg
</usr/bin/gpg>
  hplip-1:3.19.8-alt1:sisyphus+236747.3300.9.1@1567463360
    Требует: </usr/bin/gpg>
      gnupg-1.4.23-alt1:sisyphus+221902.3000.4.1@1550597453

Так же без зависимостей некоторые наверняка запускают по-умолчанию gpg, не 
искав gpg2.

Можно "Provides: gnupg", поправить hplip и ждать, где отвалится или сажать их 
на alternatives с преимуществом у gpg2.

[...]

-- 
Regards, Sergey.

Re: [devel] Provides: gnupg (Was: Новая версия GnuPG в Сизифе)

[Paul Wolneykien]

17.10.2019 16:55, Sergey V Turchin пишет:
> On Thursday, 17 October 2019 16:39:27 MSK Paul Wolneykien wrote:
> 
> [...]
>>>   2. реализацией gpg по умолчанию у нас до сих пор является gpg1
>>>
>>> (1.4), не пора ли переехать на gpg2?
>>
>>   Что будет, если я в пакете gnupg2 напишу "Provides: gnupg" ?
> Как минимум, не получится написать "Provides: /usr/bin/gpg", а
> $ apt-cache whatdepends /usr/bin/gpg
> </usr/bin/gpg>
>   hplip-1:3.19.8-alt1:sisyphus+236747.3300.9.1@1567463360
>     Требует: </usr/bin/gpg>
>       gnupg-1.4.23-alt1:sisyphus+221902.3000.4.1@1550597453
> 
> Так же без зависимостей некоторые наверняка запускают по-умолчанию gpg, не 
> искав gpg2.

  Вот именно.

> Можно "Provides: gnupg", поправить hplip и ждать, где отвалится или сажать их 
> на alternatives с преимуществом у gpg2.

  hplip это какая-то экзотика. Я исходил вот из этого:

# apt-get remove gnupg=1.4.23-alt1
Чтение списков пакетов... Завершено
Построение дерева зависимостей... Завершено
Version gnupg#1.4.23-alt1:sisyphus+221902.3000.4.1@1550597453 for
gnupg=1.4.23-alt1 is already installed
Следующие пакеты будут УДАЛЕНЫ:
  apt apt-repo apt-repo-tools apt-rsync apt-scripts gnupg hasher
  update-kernel
ВНИМАНИЕ: Будут удалены важные для работы системы пакеты

И потом

$ rpm -q --requires apt apt-repo apt-repo-tools apt-rsync apt-scripts
hasher update-kernel | grep -e 'gnupg' -e 'gpg'
gnupg
alt-gpgkeys
gnupg

  Из этого, по-моему, следует, что зависимость этих важных пакетов
именно на просто "gnupg".

Re: [devel] Provides: gnupg (Was: Новая версия GnuPG в Сизифе)

[Sergey V Turchin]

On Thursday, 17 October 2019 17:06:47 MSK Paul Wolneykien wrote:

[...]
>   Из этого, по-моему, следует, что зависимость этих важных пакетов
> именно на просто "gnupg".
Это или руками добавленная зависимость или автосконвертированная rpmbuild-ом 
из /usr/bin/gpg .

-- 
Regards, Sergey.

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 246 bytes --]

On Thu, Oct 17, 2019 at 04:39:27PM +0300, Paul Wolneykien wrote:
[...]
>   Что будет, если я в пакете gnupg2 напишу "Provides: gnupg" ?

Зачем?  Чтобы создать пользователям проблемы?
Это разные программы, они же несовместимы.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Paul Wolneykien]

В Fri, 18 Oct 2019 01:15:47 +0300
"Dmitry V. Levin" <ldv@altlinux.org> пишет:

> On Thu, Oct 17, 2019 at 04:39:27PM +0300, Paul Wolneykien wrote:
> [...]
> >   Что будет, если я в пакете gnupg2 напишу "Provides: gnupg" ?  
> 
> Зачем?  Чтобы создать пользователям проблемы?
> Это разные программы, они же несовместимы.

  А с чем конкретно gpg2 несовместим и сколько у нас таких клиентов?

  Вот Git, например, отлично себя чувствует, если ему передать
gpg.program = /usr/bin/gpg2 , Claws-Mail --- тоже, Enigmail --- тоже.
Подозреваю, что и Mutt способен адаптироваться без проблем. Кто же
остаётся?

  Те же, кому очень важно именно gnupg1 вполне могут иметь
"Requires: gnupg1", почему нет?

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

On Fri, Oct 18, 2019 at 01:36:00AM +0300, Paul Wolneykien wrote:
> В Fri, 18 Oct 2019 01:15:47 +0300, Dmitry V. Levin пишет:
> 
> > On Thu, Oct 17, 2019 at 04:39:27PM +0300, Paul Wolneykien wrote:
> > [...]
> > >   Что будет, если я в пакете gnupg2 напишу "Provides: gnupg" ?  
> > 
> > Зачем?  Чтобы создать пользователям проблемы?
> > Это разные программы, они же несовместимы.
> 
>   А с чем конкретно gpg2 несовместим и сколько у нас таких клиентов?

Предлагаю выяснить и сообщить.

>   Вот Git, например, отлично себя чувствует, если ему передать
> gpg.program = /usr/bin/gpg2 , Claws-Mail --- тоже, Enigmail --- тоже.
> Подозреваю, что и Mutt способен адаптироваться без проблем. Кто же
> остаётся?

Предлагаю выяснить и сообщить.

>   Те же, кому очень важно именно gnupg1 вполне могут иметь
> "Requires: gnupg1", почему нет?

Вы хотите, чтобы сперва они незаметно сломались, а потом кто-то их починил?
Я бы не назвал это ответственным подходом.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Vladimir D. Seleznev]

On Fri, Oct 18, 2019 at 01:36:00AM +0300, Paul Wolneykien wrote:
> В Fri, 18 Oct 2019 01:15:47 +0300
> "Dmitry V. Levin" <ldv@altlinux.org> пишет:
> 
> > On Thu, Oct 17, 2019 at 04:39:27PM +0300, Paul Wolneykien wrote:
> > [...]
> > >   Что будет, если я в пакете gnupg2 напишу "Provides: gnupg" ?  
> > 
> > Зачем?  Чтобы создать пользователям проблемы?
> > Это разные программы, они же несовместимы.
> 
>   А с чем конкретно gpg2 несовместим и сколько у нас таких клиентов?
> 
>   Вот Git, например, отлично себя чувствует, если ему передать
> gpg.program = /usr/bin/gpg2 , Claws-Mail --- тоже, Enigmail --- тоже.
> Подозреваю, что и Mutt способен адаптироваться без проблем. Кто же
> остаётся?
> 
>   Те же, кому очень важно именно gnupg1 вполне могут иметь
> "Requires: gnupg1", почему нет?

Переименование пакетов — всегда рискованное занятие.  Невозможно
полностью спрогнозировать что в итоге пойдёт не так и может сломаться. С
другой стороны, никакой беды в том, что пакет называется gnupg2 и
содержит в себе номер версии, нет. Но я уже не в первый раз сталкиваюсь
с тем, что кто-то хочет переименовать какой-нибудь pkgN в pkg. У этого
есть разумное объяснение? В чём проблема наличие числа (обычно мажорной
версии) в имени пакета?

Из пример непредвиденных последствий: после переименования grub2 в grub
у некоторых посльзователей в результате обновления был снесён пакет
grub'а. При это сам grub, конечно же никуда не делся, и не все сразу
заметили, что что-то пошло не так.

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

[devel] Переименование пакетов (was: Новая версия GnuPG в Сизифе)

[Sergey V Turchin]

On Friday, 18 October 2019 03:33:23 MSK Vladimir D wrote:

[...]
> Переименование пакетов — всегда рискованное занятие.
+1

[...]

-- 
Regards, Sergey.

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

[Paul Wolneykien]

В 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 (на который их нужно было бы явно заранее перевести).

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

[Vladimir D. Seleznev]

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-бранчах.

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

Re: [devel] Fwd: [sisyphus] файлы пакетов с disttag в имени

[Anton Farygin]

On 18.10.2019 20:26, Vladimir D. Seleznev wrote:
> Надо понимать, что мы поддерживаем репозиторий, а это подразумевает
> заботу об обратной совместимости, обновляемости систем без
> непредсказуемых поломок поведения и поддержки точечных обновлений. Что
> неизбежно приводит к накапливанию легаси и принципиальных решений
> наподобие gnupg — это первая версия gnupg. Иначе это невозможно было бы
> поддерживать. Если бы мы строили системы каждый раз заново, заново
> бутстрапя и без подразумевания вообще никаких обновлений, это всё было
> бы не принципиально, ведь каждый раз мы собирали новую систему.

Кстати, пока вспомнил  - хотел бы напомнить про обещанное на конференции 
исправление с именами файлов пакетов, в которых будет присутствовать 
disttag.

Это тоже некое legacy, несоблюдение которого уже привело к тому, что 
пришлось для проверки уникальности пакетов использовать дополнительные 
медленные механизмы (вроде контрольных сумм и чтения заголовка пакета), 
хотя можно было просто сверить по имени и размеру.

Re: [devel] Fwd: [sisyphus] файлы пакетов с disttag в имени

[Vladimir D. Seleznev]

On Fri, Oct 18, 2019 at 08:32:09PM +0300, Anton Farygin wrote:
> On 18.10.2019 20:26, Vladimir D. Seleznev wrote:
> > Надо понимать, что мы поддерживаем репозиторий, а это подразумевает
> > заботу об обратной совместимости, обновляемости систем без
> > непредсказуемых поломок поведения и поддержки точечных обновлений. Что
> > неизбежно приводит к накапливанию легаси и принципиальных решений
> > наподобие gnupg — это первая версия gnupg. Иначе это невозможно было бы
> > поддерживать. Если бы мы строили системы каждый раз заново, заново
> > бутстрапя и без подразумевания вообще никаких обновлений, это всё было
> > бы не принципиально, ведь каждый раз мы собирали новую систему.
> 
> Кстати, пока вспомнил  - хотел бы напомнить про обещанное на конференции 
> исправление с именами файлов пакетов, в которых будет присутствовать 
> disttag.
> 
> Это тоже некое legacy, несоблюдение которого уже привело к тому, что 
> пришлось для проверки уникальности пакетов использовать дополнительные 
> медленные механизмы (вроде контрольных сумм и чтения заголовка пакета), 
> хотя можно было просто сверить по имени и размеру.

mtime?

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

Re: [devel] Fwd: [sisyphus] файлы пакетов с disttag в имени

[Anton Farygin]

On 18.10.2019 20:45, Vladimir D. Seleznev wrote:
> On Fri, Oct 18, 2019 at 08:32:09PM +0300, Anton Farygin wrote:
>> On 18.10.2019 20:26, Vladimir D. Seleznev wrote:
>>> Надо понимать, что мы поддерживаем репозиторий, а это подразумевает
>>> заботу об обратной совместимости, обновляемости систем без
>>> непредсказуемых поломок поведения и поддержки точечных обновлений. Что
>>> неизбежно приводит к накапливанию легаси и принципиальных решений
>>> наподобие gnupg — это первая версия gnupg. Иначе это невозможно было бы
>>> поддерживать. Если бы мы строили системы каждый раз заново, заново
>>> бутстрапя и без подразумевания вообще никаких обновлений, это всё было
>>> бы не принципиально, ведь каждый раз мы собирали новую систему.
>> Кстати, пока вспомнил  - хотел бы напомнить про обещанное на конференции
>> исправление с именами файлов пакетов, в которых будет присутствовать
>> disttag.
>>
>> Это тоже некое legacy, несоблюдение которого уже привело к тому, что
>> пришлось для проверки уникальности пакетов использовать дополнительные
>> медленные механизмы (вроде контрольных сумм и чтения заголовка пакета),
>> хотя можно было просто сверить по имени и размеру.
> mtime?
mtime не показатель и не удобен.

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

[Paul Wolneykien]

18.10.2019 20:26, Vladimir D. Seleznev пишет:
>> Дело, естественно, не в названии пакета, а в его содержимом. Дело в
>> необходимости перенастройки других программ на /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. Ты
предлагаешь второе, но в чём преимущество? В обоих случаях нужно менять
сборочные зависимости, вносить изменения в конфигурационные файлы, а
иногда и в сам код. Менять ли "Requires: gnupg" на "Requires: gnupg1" со
всеми сопутствующими изменениями или же менять "Requires: gnupg" на
"Requires: gnupg2" тоже со всеми сопутствующими изменениями — это
абсолютно всё равно.

> Ты не можешь исправить у всех пользователей на всех уже
> установленных системах /usr/bin/gpg на /usr/bin/gpg1, 

  Почему? При обновлении новая версия пакета gnupg2 установит
/usr/bin/gpg, а новая версия gnupg установит /usr/bin/gpg1 — файловых
конфликтов между ними не будет так же, как их нет сейчас. Само собой,
если система не обновляется, то все эти "переименования" её не затронут.

> но ты можешь собирать новые пакеты

  А что за новые пакеты? Речь до сих пор была о старых пакетах. Задача
состоит в том, чтобы перевести программы из уже существующих пакетов на
использование новой версии GnuPG, которая поставляется у нас с другим
именем _файла_ (а не только пакета).

> так, чтобы у них были правильно прописаны
> зависимости на /usr/bin/gpg2. Это надёжнее в поддержке и обратно
> совместимо с уже существующими установками, и не ломает точечные
> обновления.

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

[Vladimir D. Seleznev]

On Fri, Oct 18, 2019 at 09:30:21PM +0300, Paul Wolneykien wrote:
> 18.10.2019 20:26, Vladimir D. Seleznev пишет:
> >> Дело, естественно, не в названии пакета, а в его содержимом. Дело в
> >> необходимости перенастройки других программ на /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. Ты
> предлагаешь второе, но в чём преимущество? В обоих случаях нужно менять
> сборочные зависимости, вносить изменения в конфигурационные файлы, а
> иногда и в сам код. Менять ли "Requires: gnupg" на "Requires: gnupg1" со
> всеми сопутствующими изменениями или же менять "Requires: gnupg" на
> "Requires: gnupg2" тоже со всеми сопутствующими изменениями — это
> абсолютно всё равно.

Нет, ты не понял: ты не можешь исправить зависимости на _уже_
установленных системах у всех пользователей. Поэтому гораздо проще и
предсказуемее оставить /usr/bin/gpg за первым gnupg, а переводить те
пакеты, которым нужен gnupg2, на /usr/bin/gpg2.

> > Ты не можешь исправить у всех пользователей на всех уже
> > установленных системах /usr/bin/gpg на /usr/bin/gpg1, 
> 
>   Почему? При обновлении новая версия пакета gnupg2 установит
> /usr/bin/gpg, а новая версия gnupg установит /usr/bin/gpg1 — файловых
> конфликтов между ними не будет так же, как их нет сейчас. Само собой,
> если система не обновляется, то все эти "переименования" её не затронут.

И это сломает уже установленные пакеты, которые рассчитывают, что
/usr/bin/gpg — это первый gnupg.

> > но ты можешь собирать новые пакеты
> 
>   А что за новые пакеты? Речь до сих пор была о старых пакетах. Задача
> состоит в том, чтобы перевести программы из уже существующих пакетов на
> использование новой версии GnuPG, которая поставляется у нас с другим
> именем _файла_ (а не только пакета).

Да, про другое имя файла я и писал.

> > так, чтобы у них были правильно прописаны
> > зависимости на /usr/bin/gpg2. Это надёжнее в поддержке и обратно
> > совместимо с уже существующими установками, и не ломает точечные
> > обновления.

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

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

[Paul Wolneykien]

18.10.2019 22:33, Vladimir D. Seleznev пишет:
> On Fri, Oct 18, 2019 at 09:30:21PM +0300, Paul Wolneykien wrote:
>> 18.10.2019 20:26, Vladimir D. Seleznev пишет:
>>>> Дело, естественно, не в названии пакета, а в его содержимом. Дело в
>>>> необходимости перенастройки других программ на /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. Ты
>> предлагаешь второе, но в чём преимущество? В обоих случаях нужно менять
>> сборочные зависимости, вносить изменения в конфигурационные файлы, а
>> иногда и в сам код. Менять ли "Requires: gnupg" на "Requires: gnupg1" со
>> всеми сопутствующими изменениями или же менять "Requires: gnupg" на
>> "Requires: gnupg2" тоже со всеми сопутствующими изменениями — это
>> абсолютно всё равно.
> 
> Нет, ты не понял: ты не можешь исправить зависимости на _уже_
> установленных системах у всех пользователей. Поэтому гораздо проще и
> предсказуемее оставить /usr/bin/gpg за первым gnupg, а переводить те
> пакеты, которым нужен gnupg2, на /usr/bin/gpg2.
> 
>>> Ты не можешь исправить у всех пользователей на всех уже
>>> установленных системах /usr/bin/gpg на /usr/bin/gpg1, 
>>
>>   Почему? При обновлении новая версия пакета gnupg2 установит
>> /usr/bin/gpg, а новая версия gnupg установит /usr/bin/gpg1 — файловых
>> конфликтов между ними не будет так же, как их нет сейчас. Само собой,
>> если система не обновляется, то все эти "переименования" её не затронут.
> 
> И это сломает уже установленные пакеты, которые рассчитывают, что
> /usr/bin/gpg — это первый gnupg.

  Объясни же наконец, почему уже установленные пакеты не будут обновляться?


>>> но ты можешь собирать новые пакеты
>>
>>   А что за новые пакеты? Речь до сих пор была о старых пакетах. Задача
>> состоит в том, чтобы перевести программы из уже существующих пакетов на
>> использование новой версии GnuPG, которая поставляется у нас с другим
>> именем _файла_ (а не только пакета).
> 
> Да, про другое имя файла я и писал.
> 
>>> так, чтобы у них были правильно прописаны
>>> зависимости на /usr/bin/gpg2. Это надёжнее в поддержке и обратно
>>> совместимо с уже существующими установками, и не ломает точечные
>>> обновления.
> 

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

[Vladimir D. Seleznev]

On Sat, Oct 19, 2019 at 01:02:52AM +0300, Paul Wolneykien wrote:
> >> [skip]
> >>
> > Нет, ты не понял: ты не можешь исправить зависимости на _уже_
> > установленных системах у всех пользователей. Поэтому гораздо проще и
> > предсказуемее оставить /usr/bin/gpg за первым gnupg, а переводить те
> > пакеты, которым нужен gnupg2, на /usr/bin/gpg2.
> > 
> >>> Ты не можешь исправить у всех пользователей на всех уже
> >>> установленных системах /usr/bin/gpg на /usr/bin/gpg1, 
> >>
> >>   Почему? При обновлении новая версия пакета gnupg2 установит
> >> /usr/bin/gpg, а новая версия gnupg установит /usr/bin/gpg1 — файловых
> >> конфликтов между ними не будет так же, как их нет сейчас. Само собой,
> >> если система не обновляется, то все эти "переименования" её не затронут.
> > 
> > И это сломает уже установленные пакеты, которые рассчитывают, что
> > /usr/bin/gpg — это первый gnupg.
> 
>   Объясни же наконец, почему уже установленные пакеты не будут обновляться?

Потому что речь идёт про точечные обновления.

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

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

[Paul Wolneykien]

19.10.2019 1:37, Vladimir D. Seleznev пишет:
> On Sat, Oct 19, 2019 at 01:02:52AM +0300, Paul Wolneykien wrote:
>>>> [skip]
>>>>
>>> Нет, ты не понял: ты не можешь исправить зависимости на _уже_
>>> установленных системах у всех пользователей. Поэтому гораздо проще и
>>> предсказуемее оставить /usr/bin/gpg за первым gnupg, а переводить те
>>> пакеты, которым нужен gnupg2, на /usr/bin/gpg2.
>>>
>>>>> Ты не можешь исправить у всех пользователей на всех уже
>>>>> установленных системах /usr/bin/gpg на /usr/bin/gpg1, 
>>>>
>>>>   Почему? При обновлении новая версия пакета gnupg2 установит
>>>> /usr/bin/gpg, а новая версия gnupg установит /usr/bin/gpg1 — файловых
>>>> конфликтов между ними не будет так же, как их нет сейчас. Само собой,
>>>> если система не обновляется, то все эти "переименования" её не затронут.
>>>
>>> И это сломает уже установленные пакеты, которые рассчитывают, что
>>> /usr/bin/gpg — это первый gnupg.
>>
>>   Объясни же наконец, почему уже установленные пакеты не будут обновляться?
> 
> Потому что речь идёт про точечные обновления.

  Но я же могу прописать в пакете Conflict или Obsolete и тогда
обновление перестанет быть точечным.

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

[Vladimir D. Seleznev]

On Sat, Oct 19, 2019 at 01:39:02AM +0300, Paul Wolneykien wrote:
> 19.10.2019 1:37, Vladimir D. Seleznev пишет:
> > On Sat, Oct 19, 2019 at 01:02:52AM +0300, Paul Wolneykien wrote:
> >>>> [skip]
> >>>>
> >>> Нет, ты не понял: ты не можешь исправить зависимости на _уже_
> >>> установленных системах у всех пользователей. Поэтому гораздо проще и
> >>> предсказуемее оставить /usr/bin/gpg за первым gnupg, а переводить те
> >>> пакеты, которым нужен gnupg2, на /usr/bin/gpg2.
> >>>
> >>>>> Ты не можешь исправить у всех пользователей на всех уже
> >>>>> установленных системах /usr/bin/gpg на /usr/bin/gpg1, 
> >>>>
> >>>>   Почему? При обновлении новая версия пакета gnupg2 установит
> >>>> /usr/bin/gpg, а новая версия gnupg установит /usr/bin/gpg1 — файловых
> >>>> конфликтов между ними не будет так же, как их нет сейчас. Само собой,
> >>>> если система не обновляется, то все эти "переименования" её не затронут.
> >>>
> >>> И это сломает уже установленные пакеты, которые рассчитывают, что
> >>> /usr/bin/gpg — это первый gnupg.
> >>
> >>   Объясни же наконец, почему уже установленные пакеты не будут обновляться?
> > 
> > Потому что речь идёт про точечные обновления.
> 
>   Но я же могу прописать в пакете Conflict или Obsolete и тогда
> обновление перестанет быть точечным.

Давай ещё раз что ты предлагаешь? По пунктам. Какие пакеты будут, что
они будут obsolete'еть и с чем конфликтовать, и какие экзекьютейблы,
которые требуются другим программам, в них будут упакованы.

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

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

[Paul Wolneykien]

В Sat, 19 Oct 2019 02:03:30 +0300
"Vladimir D. Seleznev" <vseleznv@altlinux.org> пишет:

> On Sat, Oct 19, 2019 at 01:39:02AM +0300, Paul Wolneykien wrote:
> > 19.10.2019 1:37, Vladimir D. Seleznev пишет:
> > > On Sat, Oct 19, 2019 at 01:02:52AM +0300, Paul Wolneykien wrote:
> > >>>> [skip]
> > >>>>
> > >>> Нет, ты не понял: ты не можешь исправить зависимости на _уже_
> > >>> установленных системах у всех пользователей. Поэтому гораздо
> > >>> проще и предсказуемее оставить /usr/bin/gpg за первым gnupg, а
> > >>> переводить те пакеты, которым нужен gnupg2, на /usr/bin/gpg2.
> > >>>
> > >>>>> Ты не можешь исправить у всех пользователей на всех уже
> > >>>>> установленных системах /usr/bin/gpg на /usr/bin/gpg1, 
> > >>>>
> > >>>>   Почему? При обновлении новая версия пакета gnupg2 установит
> > >>>> /usr/bin/gpg, а новая версия gnupg установит /usr/bin/gpg1 —
> > >>>> файловых конфликтов между ними не будет так же, как их нет
> > >>>> сейчас. Само собой, если система не обновляется, то все эти
> > >>>> "переименования" её не затронут.
> > >>>
> > >>> И это сломает уже установленные пакеты, которые рассчитывают,
> > >>> что /usr/bin/gpg — это первый gnupg.
> > >>
> > >>   Объясни же наконец, почему уже установленные пакеты не будут
> > >> обновляться?
> > > 
> > > Потому что речь идёт про точечные обновления.
> > 
> >   Но я же могу прописать в пакете Conflict или Obsolete и тогда
> > обновление перестанет быть точечным.
> 
> Давай ещё раз что ты предлагаешь? По пунктам. Какие пакеты будут, что
> они будут obsolete'еть и с чем конфликтовать, и какие экзекьютейблы,
> которые требуются другим программам, в них будут упакованы.

  Я пока думаю так:

 Name: gnupg
 Version: 1.4.23
-Release: alt1
+Release: alt2
-Provies: gpg, openpgp
+Provies: gpg1, openpgp1, gnupg1
...
-%_bindir/gpg?*
+%_bindir/gpg1

---

 Name: gnupg2
 Version: 2.2.17
-Release: alt4
+Release: alt5
+Provies: gpg, openpgp, gnupg
+Obsoletes: gnupg < 1.4.23-alt2
...
 %configure \
-	--enable-gpg-is-gpg2 \
...
+%_bindir/gpg

---

  Во всех пакетах, для которых критична совместимость со старой GnuPG
(apt, rpm?):

-Requires: gnupg
+Requires: gnupg1

или

-Requires: gpg
+Requires: gpg1

А также где-то в коде:

- ... "/usr/bin/gpg" ...
+ ... "/usr/bin/gpg1" ...


  Исходя из этого, я рассчитываю, что при точечном обновлении пакета
gnupg, будет предложено установить версию gnupg-1.4.23-alt2, а также
обновить все затронутые пакеты до версий, использующих "/usr/bin/gpg1".

  Дальше. При точечном обновлении пакета gnupg2 будет предложено
установить версию gnupg2-2.2.17-alt5, а также обновить пакет gnupg до
версии gnupg-1.4.23-alt2 и все затронутые пакеты до версий,
использующих "/usr/bin/gpg1", если пакет gnupg был установлен и не был
обновлён ранее.

  При dist-upgrade я ожидаю, что снос системы не произойдёт потому, что
новые версии пакетов, предпочитающих gnupg1 также попадут в обновление
и вытянут за собой новую версию gnupg-1.4.23-alt2, не попадающую под
Obsoletes (там строго < 1.4.23-alt2).

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

[Vladimir D. Seleznev]

On Mon, Oct 21, 2019 at 05:31:12PM +0300, Paul Wolneykien wrote:
> В Sat, 19 Oct 2019 02:03:30 +0300
> "Vladimir D. Seleznev" <vseleznv@altlinux.org> пишет:
> 
> > On Sat, Oct 19, 2019 at 01:39:02AM +0300, Paul Wolneykien wrote:
> > > 19.10.2019 1:37, Vladimir D. Seleznev пишет:
> > > > On Sat, Oct 19, 2019 at 01:02:52AM +0300, Paul Wolneykien wrote:
> > > >>>> [skip]
> > > >>>>
> > > >>> Нет, ты не понял: ты не можешь исправить зависимости на _уже_
> > > >>> установленных системах у всех пользователей. Поэтому гораздо
> > > >>> проще и предсказуемее оставить /usr/bin/gpg за первым gnupg, а
> > > >>> переводить те пакеты, которым нужен gnupg2, на /usr/bin/gpg2.
> > > >>>
> > > >>>>> Ты не можешь исправить у всех пользователей на всех уже
> > > >>>>> установленных системах /usr/bin/gpg на /usr/bin/gpg1, 
> > > >>>>
> > > >>>>   Почему? При обновлении новая версия пакета gnupg2 установит
> > > >>>> /usr/bin/gpg, а новая версия gnupg установит /usr/bin/gpg1 —
> > > >>>> файловых конфликтов между ними не будет так же, как их нет
> > > >>>> сейчас. Само собой, если система не обновляется, то все эти
> > > >>>> "переименования" её не затронут.
> > > >>>
> > > >>> И это сломает уже установленные пакеты, которые рассчитывают,
> > > >>> что /usr/bin/gpg — это первый gnupg.
> > > >>
> > > >>   Объясни же наконец, почему уже установленные пакеты не будут
> > > >> обновляться?
> > > > 
> > > > Потому что речь идёт про точечные обновления.
> > > 
> > >   Но я же могу прописать в пакете Conflict или Obsolete и тогда
> > > обновление перестанет быть точечным.
> > 
> > Давай ещё раз что ты предлагаешь? По пунктам. Какие пакеты будут, что
> > они будут obsolete'еть и с чем конфликтовать, и какие экзекьютейблы,
> > которые требуются другим программам, в них будут упакованы.
> 
>   Я пока думаю так:
> 
>  Name: gnupg
>  Version: 1.4.23
> -Release: alt1
> +Release: alt2
> -Provies: gpg, openpgp
> +Provies: gpg1, openpgp1, gnupg1
> ...
> -%_bindir/gpg?*
> +%_bindir/gpg1
> 
> ---
> 
>  Name: gnupg2
>  Version: 2.2.17
> -Release: alt4
> +Release: alt5
> +Provies: gpg, openpgp, gnupg
> +Obsoletes: gnupg < 1.4.23-alt2
> ...
>  %configure \
> -	--enable-gpg-is-gpg2 \
> ...
> +%_bindir/gpg
> 
> ---
> 
>   Во всех пакетах, для которых критична совместимость со старой GnuPG
> (apt, rpm?):
> 
> -Requires: gnupg
> +Requires: gnupg1
> 
> или
> 
> -Requires: gpg
> +Requires: gpg1
> 
> А также где-то в коде:
> 
> - ... "/usr/bin/gpg" ...
> + ... "/usr/bin/gpg1" ...
> 
> 
>   Исходя из этого, я рассчитываю, что при точечном обновлении пакета
> gnupg, будет предложено установить версию gnupg-1.4.23-alt2, а также
> обновить все затронутые пакеты до версий, использующих "/usr/bin/gpg1".

Проблема в том, что при точечном обновлении gnupg не будет предложено
обновить всех клиентов gnupg до тех, которые понимают, что /usr/bin/gpg
— это /usr/bin/gpg2, а не бинарник из gnupg. Я не готов сказать, как
поведёт себя apt, т.к. это слабопредсказуемо, но по опыту могу
предположить следующие два варианта: либо будут удалены из системы все
клиенты gnupg (наиболее вероятно), либо будет доустановлен gnupg2, и
клиенты gnupg сломаются в рантайме.

>   Дальше. При точечном обновлении пакета gnupg2 будет предложено
> установить версию gnupg2-2.2.17-alt5, а также обновить пакет gnupg до
> версии gnupg-1.4.23-alt2 и все затронутые пакеты до версий,
> использующих "/usr/bin/gpg1", если пакет gnupg был установлен и не был
> обновлён ранее.

Подозреваю, что в этом случае вылезет неявный конфликт на установленную
версию gnupg, и установка обвалится.

>   При dist-upgrade я ожидаю, что снос системы не произойдёт потому, что
> новые версии пакетов, предпочитающих gnupg1 также попадут в обновление
> и вытянут за собой новую версию gnupg-1.4.23-alt2, не попадающую под
> Obsoletes (там строго < 1.4.23-alt2).

Также как и при точечном обновлении gnupg из первого цитирования, слабо
прогнозирую, что произойдёт, но по опыту предполагаю, что как раз-таки
будет предложено снести полсистемы.

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

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

[Sergey V Turchin]

On Monday, 21 October 2019 19:27:32 MSK Vladimir D wrote:

[...]
> Проблема в том, что при точечном обновлении gnupg не будет предложено
> обновить всех клиентов gnupg до тех, которые понимают, что /usr/bin/gpg
> — это /usr/bin/gpg2, а не бинарник из gnupg. Я не готов сказать, как
> поведёт себя apt, т.к. это слабопредсказуемо, но по опыту могу
> предположить следующие два варианта: либо будут удалены из системы все
> клиенты gnupg (наиболее вероятно)
Даже если всех их исправить и на всех их будет стоять
Conflicts: pkg < Version-FixedRelease
, т.к. наш apt уже давно не стремиться обновить в подобных случаях.
А может просто сказать "не могу", если зацепится по зависимостям за ещё какую 
любую одну вдруг всплывшую проблему, а их борода будет вполне немалая.

[...]

-- 
Regards, Sergey.

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

On Mon, Oct 21, 2019 at 05:31:12PM +0300, Paul Wolneykien wrote:
[...]
>   Я пока думаю так:
> 
>  Name: gnupg
>  Version: 1.4.23
> -Release: alt1
> +Release: alt2
> -Provies: gpg, openpgp
> +Provies: gpg1, openpgp1, gnupg1
> ...
> -%_bindir/gpg?*
> +%_bindir/gpg1
> 
> ---
> 
>  Name: gnupg2
>  Version: 2.2.17
> -Release: alt4
> +Release: alt5
> +Provies: gpg, openpgp, gnupg
> +Obsoletes: gnupg < 1.4.23-alt2
> ...
>  %configure \
> -	--enable-gpg-is-gpg2 \
> ...
> +%_bindir/gpg

Я думаю, что лучше сделать примерно также, как мы сделали при переезде
с bash3 на bash4:

1. переименовать gnupg в gnupg1, запаковать gnupg со ссылками на файлы в gnupg1;
2. немного подождать;
3. поменять в gnupg ссылки с gnupg1 на gnupg2.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Paul Wolneykien]

В Tue, 22 Oct 2019 13:40:09 +0300
"Dmitry V. Levin" <ldv@altlinux.org> пишет:

> On Mon, Oct 21, 2019 at 05:31:12PM +0300, Paul Wolneykien wrote:
> [...]
>  [...]  
> 
> Я думаю, что лучше сделать примерно также, как мы сделали при переезде
> с bash3 на bash4:
> 
> 1. переименовать gnupg в gnupg1,...

  Тогда первый ход за тобой.

> ...запаковать gnupg со ссылками на файлы в gnupg1;

  Не совсем понял: запаковать _программу_ gnupg, т.е. gpg?

  Или же сделать новый пакет "gnupg" _вдобавок_ к переименованному в
gnupg1 --- в этом новом пакете gnupg будут лежать симлинки на файлы,
предоставляемые пакетом gnupg1, так?

> 2. немного подождать;
> 3. поменять в gnupg ссылки с gnupg1 на gnupg2.

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]

On Tue, Oct 22, 2019 at 02:09:26PM +0300, Paul Wolneykien wrote:
> В Tue, 22 Oct 2019 13:40:09 +0300 Dmitry V. Levin пишет:
> > On Mon, Oct 21, 2019 at 05:31:12PM +0300, Paul Wolneykien wrote:
> > [...]
> >  [...]  
> > 
> > Я думаю, что лучше сделать примерно также, как мы сделали при переезде
> > с bash3 на bash4:
> > 
> > 1. переименовать gnupg в gnupg1,...
> 
>   Тогда первый ход за тобой.

Переименовать gnupg в gnupg1 несложно, по крайней мере, в федоре с этим
справились.  Сохранение в репозитории пакета по имени gnupg, который будет
вытягивать gnupg1, сделает эту миграцию безболезненной.

> > ...запаковать gnupg со ссылками на файлы в gnupg1;
> 
>   Не совсем понял: запаковать _программу_ gnupg, т.е. gpg?

Нет.

>   Или же сделать новый пакет "gnupg" _вдобавок_ к переименованному в
> gnupg1 --- в этом новом пакете gnupg будут лежать симлинки на файлы,
> предоставляемые пакетом gnupg1, так?

Да, так.  Если посмотреть содержимое пакета bash, там это хорошо видно.

> > 2. немного подождать;
> > 3. поменять в gnupg ссылки с gnupg1 на gnupg2.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 3516 bytes --]

On Sat, 19 Oct 2019 01:37:53 +0300 Vladimir D. Seleznev wrote:
> On Sat, Oct 19, 2019 at 01:02:52AM +0300, Paul Wolneykien wrote:
> > >> [skip]
> > >>
> > > Нет, ты не понял: ты не можешь исправить зависимости на _уже_
> > > установленных системах у всех пользователей. Поэтому гораздо проще и
> > > предсказуемее оставить /usr/bin/gpg за первым gnupg, а переводить те
> > > пакеты, которым нужен gnupg2, на /usr/bin/gpg2.
> > > 
> > >>> Ты не можешь исправить у всех пользователей на всех уже
> > >>> установленных системах /usr/bin/gpg на /usr/bin/gpg1, 
> > >>
> > >>   Почему? При обновлении новая версия пакета gnupg2 установит
> > >> /usr/bin/gpg, а новая версия gnupg установит /usr/bin/gpg1 — файловых
> > >> конфликтов между ними не будет так же, как их нет сейчас. Само собой,
> > >> если система не обновляется, то все эти "переименования" её не затронут.
> > > 
> > > И это сломает уже установленные пакеты, которые рассчитывают, что
> > > /usr/bin/gpg — это первый gnupg.
> > 
> >   Объясни же наконец, почему уже установленные пакеты не будут обновляться?
> 
> Потому что речь идёт про точечные обновления.
 
Насколько я помню, в sisyphus мы поддерживаем только dist-upgrade.
Если кто-то держит у себя sisyphus годовой давности и делает лишь
точечные обновления, то проблем будем много больше, чем с gnupg.

Думаю, реальная причина этого спора в том, что у нас часть людей
будет рогами упираться до последнего, но использовать gnupg1.

Между прочим, я ещё полтора года назад на своей системе зафорсил
симлинк gpg -> /usr/bin/gpg2 (сделано это через /usr/local/bin,
который в PATH прописан приоритетнее путей без local), потому что
меня достало перенастраивать все приложения. Всё прекрасно работает
с gpg как gpg2. Так что все разговоры о том, как поломаются бедные
несчастные пакеты, ожидающие gpg1 — это пустословие. Поломаться
могут только наши собственные скрипты а-ля girar, но это легко
исправить.

gpg1 уязвим к ряду атак (keyring poisioning, например) и не
понимает современные ключи (ed25519, rsa8192), так что его время
ушло и со временем пакет следует удалить из соображений обеспечения
безопасности и совместимости.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

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

[Dmitry V. Levin]

On Sat, Oct 19, 2019 at 06:20:31AM +0200, Andrey Savchenko wrote:
> On Sat, 19 Oct 2019 01:37:53 +0300 Vladimir D. Seleznev wrote:
> > On Sat, Oct 19, 2019 at 01:02:52AM +0300, Paul Wolneykien wrote:
> > > >> [skip]
> > > >>
> > > > Нет, ты не понял: ты не можешь исправить зависимости на _уже_
> > > > установленных системах у всех пользователей. Поэтому гораздо проще и
> > > > предсказуемее оставить /usr/bin/gpg за первым gnupg, а переводить те
> > > > пакеты, которым нужен gnupg2, на /usr/bin/gpg2.
> > > > 
> > > >>> Ты не можешь исправить у всех пользователей на всех уже
> > > >>> установленных системах /usr/bin/gpg на /usr/bin/gpg1, 
> > > >>
> > > >>   Почему? При обновлении новая версия пакета gnupg2 установит
> > > >> /usr/bin/gpg, а новая версия gnupg установит /usr/bin/gpg1 — файловых
> > > >> конфликтов между ними не будет так же, как их нет сейчас. Само собой,
> > > >> если система не обновляется, то все эти "переименования" её не затронут.
> > > > 
> > > > И это сломает уже установленные пакеты, которые рассчитывают, что
> > > > /usr/bin/gpg — это первый gnupg.
> > > 
> > >   Объясни же наконец, почему уже установленные пакеты не будут обновляться?
> > 
> > Потому что речь идёт про точечные обновления.
>  
> Насколько я помню, в sisyphus мы поддерживаем только dist-upgrade.

Нет, не только, мы поддерживаем точечные обновления.


-- 
ldv

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

[Anton Farygin]

On 19.10.2019 9:45, Dmitry V. Levin wrote:
>>>>    Объясни же наконец, почему уже установленные пакеты не будут обновляться?
>>> Потому что речь идёт про точечные обновления.
>>   
>> Насколько я помню, в sisyphus мы поддерживаем только dist-upgrade.
> Нет, не только, мы поддерживаем точечные обновления.

Я бы сказал так - мы стараемся поддерживать точечные обновления, но 
бывает что они не работают, т.к. точечные обновления мы не тестируем (я 
про stable ветки).

Попытки тестировать точечные обновления у нас были, но они показали что 
мы не в состоянии стопроцентно гарантировать возможность точечных 
обновлений даже в пределах одной stable ветки.

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

[Paul Wolneykien]

В Sat, 19 Oct 2019 06:20:31 +0200
Andrey Savchenko <bircoph@altlinux.org> пишет:

> Между прочим, я ещё полтора года назад на своей системе зафорсил
> симлинк gpg -> /usr/bin/gpg2 (сделано это через /usr/local/bin,
> который в PATH прописан приоритетнее путей без local), потому что
> меня достало перенастраивать все приложения. Всё прекрасно работает
> с gpg как gpg2.

  В том числе и apt, и rpm ?

> Так что все разговоры о том, как поломаются бедные
> несчастные пакеты, ожидающие gpg1 — это пустословие. Поломаться
> могут только наши собственные скрипты а-ля girar, но это легко
> исправить.

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

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1502 bytes --]

On Mon, 21 Oct 2019 17:32:31 +0300 Paul Wolneykien wrote:
> В Sat, 19 Oct 2019 06:20:31 +0200
> Andrey Savchenko <bircoph@altlinux.org> пишет:
> 
> > Между прочим, я ещё полтора года назад на своей системе зафорсил
> > симлинк gpg -> /usr/bin/gpg2 (сделано это через /usr/local/bin,
> > который в PATH прописан приоритетнее путей без local), потому что
> > меня достало перенастраивать все приложения. Всё прекрасно работает
> > с gpg как gpg2.
> 
>   В том числе и apt, и rpm ?

У меня указанный выше override сделан на уровне пользователя, от
него rpm и apt работают без нареканий. Под рутом при обновлении
системы не проверял.
 
> > Так что все разговоры о том, как поломаются бедные
> > несчастные пакеты, ожидающие gpg1 — это пустословие. Поломаться
> > могут только наши собственные скрипты а-ля girar, но это легко
> > исправить.
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]