[devel] libpaper update (was: [#325166] DONE (try 15) libpaper.git=2.1.1-alt1 boomaga.git=3.0.0-alt1.2 xmlto.git=0.0.28-alt3 ...)

[devel] libpaper update (was: [#325166] DONE (try 15) libpaper.git=2.1.1-alt1 boomaga.git=3.0.0-alt1.2 xmlto.git=0.0.28-alt3 ...)

[Gleb Fotengauer-Malinovskiy]

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

Hi,

On Mon, Jul 24, 2023 at 09:01:00AM +0000, Girar pender (fidel) wrote:
> #102 build 2.1.1-alt1 from /people/fidel/packages/libpaper.git fetched at 2023-Jul-21 12:41:18
> #500 build 3.0.0-alt1.2 from /people/fidel/packages/boomaga.git fetched at 2023-Jul-19 13:45:01
> #600 build 0.0.28-alt3 from /gears/x/xmlto.git fetched at 2023-Jul-19 17:28:11 from sisyphus
> #620 build 1.1.28-alt2 from /people/fidel/packages/libpaper1.git fetched at 2023-Jul-21 09:41:37

К сожалению, качество этого обновления оказалось очень низким. От
кандидата, проходящего join, конечно, не ожидается, что он не будет делать
таких ошибок, но для этого и нужен ментор.

Я исправил всё, что увидел плохого, потому что очень не хотел видеть это в
Сизифе, который будет опубликован этой ночью.

On Mon, Jul 24, 2023 at 06:43:10PM +0000, Girar pender (glebfm) wrote:
> https://git.altlinux.org/tasks/archive/done/_317/325500/logs/events.3.1.log
> #140 libpaper 2.1.1-alt1 -> 2:2.1.1-alt2
>  Mon Jul 24 2023 Gleb F-Malinovskiy <glebfm@altlinux> 2:2.1.1-alt2
>  - NMU:
>    - Removed unused patches.
>    - Added a call to the %autoreconf macro to prevent the generation of rpaths
>      in the ELF files.
>    - libpaper2: removed the 'Obsoletes: libpaper' tag because these packages
>      provide completely different sonames, allowing them to be installed
>      simultaneously.
>    - libpaper2: removed the 'Provides: libpaper' because it doesn't make any
>      sense either.
>  [...]
    - libpaper2: added 'Conflicts: libpaper < 1.1.28-alt3' due to conflicting
      versions of the /usr/bin/paperconf utility.
    - Enabled strict mode for the verify-elf check.
    - Enabled rpm-build checks for unpackaged files and stripped files.
> #200 libpaper1 1.1.28-alt2 -> 1.1.28-alt3
>  Mon Jul 24 2023 Gleb F-Malinovskiy <glebfm@altlinux> 1.1.28-alt3
>  - NMU:
>    - Reverted the libpaper1 package name to libpaper to prevent an unnecessary
>      relocation of the libpaper.so.1 soname provider.
>    - libpaper: added Provides: libpaper1 and Obsoletes: libpaper1 because
>      it has already been uploaded into the Sisyphus repository.
>    - Fixed the License: tag (GPL -> GPL-2.0-only).
>    - Fixed libpaper Group: tag (System/Libraries -> System/Legacy libraries).

1. Переименование бинарного пакета libpaper в libpaper1 было ошибкой
потому что таким образом soname libpaper.so.1 переезжает в другой пакет.
К тому же, переименованный пакет даже не содержит Provides+Obsoletes, т.е.
не будет обновлён, а при установке будет конфликтовать со старым пакетом.
2. Между пакетами libpaper2 и libpaper < 1.1.28-alt1 отсутствовал явный
конфликт, хотя эти пакеты содержат разные версии /usr/bin/paperconf.
3. '%set_verify_elf_method rpath=relaxed' из-за попадания %_libdir в RPATH
это просто стыдно, мне сложно даже как-то комментировать.

P.S. Здесь могла быть ваша реклама^W^W^W^Wдолжно было быть письмо про
autoconf 2.71, но оно, увы, будет уже завтра.

-- 
glebfm

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

Re: [devel] libpaper update (was: [#325166] DONE (try 15) libpaper.git=2.1.1-alt1 boomaga.git=3.0.0-alt1.2 xmlto.git=0.0.28-alt3 ...)

[Vitaly Lipatov]

Gleb Fotengauer-Malinovskiy писал(а) 24.7.23 23:18:
> Hi,
> 
> On Mon, Jul 24, 2023 at 09:01:00AM +0000, Girar pender (fidel) wrote:
>> #102 build 2.1.1-alt1 from /people/fidel/packages/libpaper.git fetched 
>> at 2023-Jul-21 12:41:18
>> #500 build 3.0.0-alt1.2 from /people/fidel/packages/boomaga.git 
>> fetched at 2023-Jul-19 13:45:01
>> #600 build 0.0.28-alt3 from /gears/x/xmlto.git fetched at 2023-Jul-19 
>> 17:28:11 from sisyphus
>> #620 build 1.1.28-alt2 from /people/fidel/packages/libpaper1.git 
>> fetched at 2023-Jul-21 09:41:37
> 
> К сожалению, качество этого обновления оказалось очень низким. От
> кандидата, проходящего join, конечно, не ожидается, что он не будет 
> делать
> таких ошибок, но для этого и нужен ментор.
Спасибо за иллюстрацию того, что простое обновление пакета со сменой 
soname библиотеки выглядит невразумительно и неоправданно сложным 
благодаря Shared Policy Libs. Тут даже лучше начинаешь понимать те 
апстримы, которые делают несовместимые изменения, не меняя soname.

> Я исправил всё, что увидел плохого, потому что очень не хотел видеть 
> это в
> Сизифе, который будет опубликован этой ночью.
Спасибо за исправления! Попробуем сделать для Shared Libs Policy пример 
на основе этой сиутации.

>>    - libpaper2: removed the 'Provides: libpaper' because it doesn't 
>> make any
>>      sense either.
Если что, libpaper был нужен для тех пакетов, которые указывали 
Requires: libpaper ради того, чтобы получить /usr/bin/paperconf. Если вы 
его убрали, видимо, такие пакеты лишатся нужной им команды.

>>  [...]
>     - libpaper2: added 'Conflicts: libpaper < 1.1.28-alt3' due to 
> conflicting
>       versions of the /usr/bin/paperconf utility.
>     - Enabled strict mode for the verify-elf check.
>     - Enabled rpm-build checks for unpackaged files and stripped files.
>> #200 libpaper1 1.1.28-alt2 -> 1.1.28-alt3
>>  Mon Jul 24 2023 Gleb F-Malinovskiy <glebfm@altlinux> 1.1.28-alt3
>>  - NMU:
>>    - Reverted the libpaper1 package name to libpaper to prevent an 
>> unnecessary
>>      relocation of the libpaper.so.1 soname provider.
>>    - libpaper: added Provides: libpaper1 and Obsoletes: libpaper1 
>> because
>>      it has already been uploaded into the Sisyphus repository.
>>    - Fixed the License: tag (GPL -> GPL-2.0-only).
>>    - Fixed libpaper Group: tag (System/Libraries -> System/Legacy 
>> libraries).
> 
> 1. Переименование бинарного пакета libpaper в libpaper1 было ошибкой
> потому что таким образом soname libpaper.so.1 переезжает в другой 
> пакет.
А что плохого в том, что библиотека переезжает в другой пакет? Выглядит 
как тайное знание.
Я вот считаю, что вообще плохо пакеты переименовывать, и бинарный 
libpaper должен был и остаться libpaper.

> К тому же, переименованный пакет даже не содержит Provides+Obsoletes, 
> т.е.
> не будет обновлён, а при установке будет конфликтовать со старым 
> пакетом.
Вообще-то обновление проверялось, и старый пакет успешно заменялся:
  $ sudo apt-repo test 325166
Получено: 1 http://git.altlinux.org repo/325166/i586 release [1672B]
Получено: 2 http://mirror.yandex.ru altlinux/Sisyphus/i586 release 
[4238B]
Получено 5910B за 0s (115kB/s).
Найдено http://git.altlinux.org repo/325166/i586/task pkglist
Найдено http://git.altlinux.org repo/325166/i586/task release
Найдено http://mirror.yandex.ru altlinux/Sisyphus/i586/debuginfo pkglist
Найдено http://mirror.yandex.ru altlinux/Sisyphus/i586/debuginfo release
Чтение списков пакетов... Завершено
Построение дерева зависимостей... Завершено
Чтение списков пакетов... Завершено
Построение дерева зависимостей... Завершено
Последняя версия boomaga уже установлена.
Последняя версия xmlto уже установлена.
Следующие дополнительные пакеты будут установлены:
   libpaper-devel texlive-dist texlive-fonts-sources texlive-texmf
Следующие пакеты будут ОБНОВЛЕНЫ:
   libpaper-devel
Следующие пакеты будут ЗАМЕНЕНЫ:
   libpaper (by libpaper2)
Следующие НОВЫЕ пакеты будут установлены:
   libpaper1 libpaper2 paper texlive-dist texlive-fonts-sources 
texlive-texmf xmlto-tex
1 будет обновлено, 7 новых установлено, 1 пакетов будет заменено, 0 
пакетов будет удалено и 315 не будет обновлено.
Необходимо получить 65,5kB/746MB архивов.
После распаковки потребуется дополнительно 1976MB дискового 
пространства.
Продолжить? [Y/n]

> 2. Между пакетами libpaper2 и libpaper < 1.1.28-alt1 отсутствовал явный
> конфликт, хотя эти пакеты содержат разные версии /usr/bin/paperconf.
+1

> 3. '%set_verify_elf_method rpath=relaxed' из-за попадания %_libdir в 
> RPATH
> это просто стыдно, мне сложно даже как-то комментировать.
А кому стыдно? Тому, кто не написал, почему %_libdir в RPATH это плохо 
на странице
https://www.altlinux.org/ProblemWithVerifyELFAndRPATH
?
Возможно, что это я один не знаю, что такого в %_libdir в RPATH, а 
возможно, что знает только 3 человека из Тим. Проверять будем?


-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] libpaper update (was: [#325166] DONE (try 15) libpaper.git=2.1.1-alt1 boomaga.git=3.0.0-alt1.2 xmlto.git=0.0.28-alt3 ...)

[Gleb Fotengauer-Malinovskiy]

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

On Tue, Jul 25, 2023 at 01:21:01AM +0300, Vitaly Lipatov wrote:
> Gleb Fotengauer-Malinovskiy писал(а) 24.7.23 23:18:
> > Hi,
> > 
> > On Mon, Jul 24, 2023 at 09:01:00AM +0000, Girar pender (fidel) wrote:
> >> #102 build 2.1.1-alt1 from /people/fidel/packages/libpaper.git fetched 
> >> at 2023-Jul-21 12:41:18
> >> #500 build 3.0.0-alt1.2 from /people/fidel/packages/boomaga.git 
> >> fetched at 2023-Jul-19 13:45:01
> >> #600 build 0.0.28-alt3 from /gears/x/xmlto.git fetched at 2023-Jul-19 
> >> 17:28:11 from sisyphus
> >> #620 build 1.1.28-alt2 from /people/fidel/packages/libpaper1.git 
> >> fetched at 2023-Jul-21 09:41:37
> > 
> > К сожалению, качество этого обновления оказалось очень низким. От
> > кандидата, проходящего join, конечно, не ожидается, что он не будет 
> > делать
> > таких ошибок, но для этого и нужен ментор.
> Спасибо за иллюстрацию того, что простое обновление

Я вот считаю, что это была довольно сложная задача.

> пакета со сменой 
> soname библиотеки выглядит невразумительно и неоправданно сложным 
> благодаря Shared Policy Libs.

Shared Libs Policy всегда была связана с необходимостью.  Вообще, практика
показывает, что если библиотека сразу собрана с учётом существования
Shared Libs Policy и опыта обновления библиотек со сменой soname, то и
обновление происходит проще.

> Тут даже лучше начинаешь понимать те 
> апстримы, которые делают несовместимые изменения, не меняя soname.

Я не понимаю связи.

> > Я исправил всё, что увидел плохого, потому что очень не хотел видеть 
> > это в
> > Сизифе, который будет опубликован этой ночью.
> Спасибо за исправления! Попробуем сделать для Shared Libs Policy пример 
> на основе этой сиутации.
> 
> >>    - libpaper2: removed the 'Provides: libpaper' because it doesn't 
> >> make any
> >>      sense either.
> Если что, libpaper был нужен для тех пакетов, которые указывали 
> Requires: libpaper ради того, чтобы получить /usr/bin/paperconf. Если вы 
> его убрали, видимо, такие пакеты лишатся нужной им команды.

Частичный Provides: это тоже неправильно.  Тут можно только исправить
все такие пакеты.
Вообще, эту утилиту нужно паковать отдельно, так не делалось раньше, но
при обновлении libpaper стоило это исправить, я даже скажу, что всё ещё
не поздно.

> >>  [...]
> >     - libpaper2: added 'Conflicts: libpaper < 1.1.28-alt3' due to 
> > conflicting
> >       versions of the /usr/bin/paperconf utility.
> >     - Enabled strict mode for the verify-elf check.
> >     - Enabled rpm-build checks for unpackaged files and stripped files.
> >> #200 libpaper1 1.1.28-alt2 -> 1.1.28-alt3
> >>  Mon Jul 24 2023 Gleb F-Malinovskiy <glebfm@altlinux> 1.1.28-alt3
> >>  - NMU:
> >>    - Reverted the libpaper1 package name to libpaper to prevent an 
> >> unnecessary
> >>      relocation of the libpaper.so.1 soname provider.
> >>    - libpaper: added Provides: libpaper1 and Obsoletes: libpaper1 
> >> because
> >>      it has already been uploaded into the Sisyphus repository.
> >>    - Fixed the License: tag (GPL -> GPL-2.0-only).
> >>    - Fixed libpaper Group: tag (System/Libraries -> System/Legacy 
> >> libraries).
> > 
> > 1. Переименование бинарного пакета libpaper в libpaper1 было ошибкой
> > потому что таким образом soname libpaper.so.1 переезжает в другой 
> > пакет.
> А что плохого в том, что библиотека переезжает в другой пакет? Выглядит 
> как тайное знание.

https://www.altlinux.org/Shared_Libs_Policy
  «...можно столкнуться с багофичей apt: он плохо переносит переименования
  пакетов в случае, когда содержимое старой версии пакета переносится в
  пакет с новым именем, но при этом пакет со старым именем остаётся
  существовать».

> Я вот считаю, что вообще плохо пакеты переименовывать, и бинарный 
> libpaper должен был и остаться libpaper.

Тем не менее, ты заапрувил такое переименование.

> > К тому же, переименованный пакет даже не содержит Provides+Obsoletes, 
> > т.е.
> > не будет обновлён, а при установке будет конфликтовать со старым 
> > пакетом.
> Вообще-то обновление проверялось, и старый пакет успешно заменялся:
>   $ sudo apt-repo test 325166
> Получено: 1 http://git.altlinux.org repo/325166/i586 release [1672B]
> Получено: 2 http://mirror.yandex.ru altlinux/Sisyphus/i586 release 
> [4238B]
> Получено 5910B за 0s (115kB/s).
> Найдено http://git.altlinux.org repo/325166/i586/task pkglist
> Найдено http://git.altlinux.org repo/325166/i586/task release
> Найдено http://mirror.yandex.ru altlinux/Sisyphus/i586/debuginfo pkglist
> Найдено http://mirror.yandex.ru altlinux/Sisyphus/i586/debuginfo release
> Чтение списков пакетов... Завершено
> Построение дерева зависимостей... Завершено
> Чтение списков пакетов... Завершено
> Построение дерева зависимостей... Завершено
> Последняя версия boomaga уже установлена.
> Последняя версия xmlto уже установлена.
> Следующие дополнительные пакеты будут установлены:
>    libpaper-devel texlive-dist texlive-fonts-sources texlive-texmf
> Следующие пакеты будут ОБНОВЛЕНЫ:
>    libpaper-devel
> Следующие пакеты будут ЗАМЕНЕНЫ:
>    libpaper (by libpaper2)
> Следующие НОВЫЕ пакеты будут установлены:
>    libpaper1 libpaper2 paper texlive-dist texlive-fonts-sources 
> texlive-texmf xmlto-tex
> 1 будет обновлено, 7 новых установлено, 1 пакетов будет заменено, 0 
> пакетов будет удалено и 315 не будет обновлено.
> Необходимо получить 65,5kB/746MB архивов.
> После распаковки потребуется дополнительно 1976MB дискового 
> пространства.
> Продолжить? [Y/n]

Да, если устанавливать оба пакета одновременно, то проблема, конечно, не
проявится.

> > 2. Между пакетами libpaper2 и libpaper < 1.1.28-alt1 отсутствовал явный
> > конфликт, хотя эти пакеты содержат разные версии /usr/bin/paperconf.
> +1
> 
> > 3. '%set_verify_elf_method rpath=relaxed' из-за попадания %_libdir в 
> > RPATH
> > это просто стыдно, мне сложно даже как-то комментировать.
> А кому стыдно?

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

> Тому, кто не написал, почему %_libdir в RPATH это плохо 
> на странице
> https://www.altlinux.org/ProblemWithVerifyELFAndRPATH
> ?

Похоже, эта статья по большей части была написана вообще до появления
проверки про стандартные пути.  Хороший повод её обновить.

> Возможно, что это я один не знаю, что такого в %_libdir в RPATH, а 
> возможно, что знает только 3 человека из Тим. Проверять будем?

Те или иные проверки rpath существуют в Альте с 2002 года, а проверка на
наличие стандартных каталогов с 2011 года.  Я удивлён, что ты не
поинтересовался за столько времени, но учить кандидата в Team не
интересоваться такими вещами это совсем другое дело.

В 2011 году при добавлении этой проверки было письмо с иллюстрацией того,
почему это плохо:
https://lore.altlinux.org/devel/20111212145709.GE24413@altlinux.org/

-- 
glebfm

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

Re: [devel] libpaper update

[Alexey V. Vissarionov]

Good ${greeting_time}!

On 2023-07-25 12:16:13 +0400, Gleb Fotengauer-Malinovskiy wrote:

 >>>> - libpaper2: removed the 'Provides: libpaper' because it
 >>>> doesn't make any sense either.
 >> Если что, libpaper был нужен для тех пакетов, которые указывали
 >> Requires: libpaper ради того, чтобы получить /usr/bin/paperconf.
 >> Если вы его убрали, видимо, такие пакеты лишатся нужной им команды.
 > Частичный Provides: это тоже неправильно. Тут можно только
 > исправить все такие пакеты.  Вообще, эту утилиту нужно паковать
 > отдельно, так не делалось раньше, но при обновлении libpaper
 > стоило это исправить, я даже скажу, что всё ещё не поздно.

Более того, исправить это необходимо: от пакета libpaper ожидается
собственно библиотека, а /usr/bin/paperconf и аналогичным приблудам
место в отдельном пакете - libpaper-utils или просто paperconf (они
могут требовать libpaper, но пакет libpaper их требовать не должен).


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] libpaper update

[Vitaly Lipatov]

Alexey V. Vissarionov писал(а) 25.7.23 11:52:
...
> Более того, исправить это необходимо: от пакета libpaper ожидается
> собственно библиотека, а /usr/bin/paperconf и аналогичным приблудам
> место в отдельном пакете - libpaper-utils или просто paperconf (они
> могут требовать libpaper, но пакет libpaper их требовать не должен).

Если кому-то нужен /usr/bin/paperconf, у него должно быть
Requires:  /usr/bin/paperconf
и название пакета значения не имеет.

Поэтому чем обусловлена необходимость, не ясно.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] libpaper update

[Sergey V Turchin]

On Tuesday, 25 July 2023 15:39:25 MSK Vitaly Lipatov wrote:
> Alexey V. Vissarionov писал(а) 25.7.23 11:52:
> ...
> 
> > Более того, исправить это необходимо: от пакета libpaper ожидается
> > собственно библиотека, а /usr/bin/paperconf и аналогичным приблудам
> > место в отдельном пакете - libpaper-utils или просто paperconf (они
> > могут требовать libpaper, но пакет libpaper их требовать не должен).
> 
> Если кому-то нужен /usr/bin/paperconf, у него должно быть
> Requires:  /usr/bin/paperconf
> и название пакета значения не имеет.
А если не нужен? ;-)
 
> Поэтому чем обусловлена необходимость, не ясно.
1. Чтобы не было файлового конфликта у любых релизов libpaper и libpaper2
2. Чтоб тот, кто `apt-get install /usr/bin/paperconf` не профукал его при 
dist-upgrtade, когда /usr/bin/paperconf сбежал в libpaper2.
-- 
Regards, Sergey.

Re: [devel] libpaper update

[Vitaly Lipatov]

Sergey V Turchin писал(а) 25.7.23 15:47:
> On Tuesday, 25 July 2023 15:39:25 MSK Vitaly Lipatov wrote:
>> Alexey V. Vissarionov писал(а) 25.7.23 11:52:
>> ...
>> 
>> > Более того, исправить это необходимо: от пакета libpaper ожидается
>> > собственно библиотека, а /usr/bin/paperconf и аналогичным приблудам
>> > место в отдельном пакете - libpaper-utils или просто paperconf (они
>> > могут требовать libpaper, но пакет libpaper их требовать не должен).
>> 
>> Если кому-то нужен /usr/bin/paperconf, у него должно быть
>> Requires:  /usr/bin/paperconf
>> и название пакета значения не имеет.
> А если не нужен? ;-)
Я согласен, если, как Алексей ниже написал, утилита тянет много внешнего 
и ненужного библиотеке.

>> Поэтому чем обусловлена необходимость, не ясно.
> 1. Чтобы не было файлового конфликта у любых релизов libpaper и 
> libpaper2
> 2. Чтоб тот, кто `apt-get install /usr/bin/paperconf` не профукал его 
> при
> dist-upgrtade, когда /usr/bin/paperconf сбежал в libpaper2.
Тогда это вопрос изначально правильной упаковки. И нужно более явное 
требование отдельной упаковки утилит в случае, если они один с 
библиотекой.

У меня вот в системе на 2,5 тысячи lib-пакетов действительно только три 
сотни бинарников:
$ epm qp ^lib | wc -l
  $ rpm -qa | grep -E -i --color -- "(^lib)"
2663

$ epm qp ^lib | grep -E -v "(devel|util|tool|common)" | epm ql | grep 
bin/ | wc -l
304

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] libpaper update

[Sergey V Turchin]

On Tuesday, 25 July 2023 16:24:41 MSK Vitaly Lipatov wrote:

[...]
> >> Поэтому чем обусловлена необходимость, не ясно.
> > 1. Чтобы не было файлового конфликта у любых релизов libpaper и
> > libpaper2
> > 2. Чтоб тот, кто `apt-get install /usr/bin/paperconf` не профукал его
> > при
> > dist-upgrtade, когда /usr/bin/paperconf сбежал в libpaper2.
> 
> Тогда это вопрос изначально правильной упаковки. И нужно более явное
> требование отдельной упаковки утилит в случае, если они один с
> библиотекой.
Тут относительно. Если я уверен, что имя пакета не поменяется, то в некоторых 
случаях пакую с библиотекой файлы, которые там не слишком красиво смотрятся.

[...]

-- 
Regards, Sergey.

Re: [devel] libpaper update

[Anton Farygin]

On 25.07.2023 16:24, Vitaly Lipatov wrote:
> Sergey V Turchin писал(а) 25.7.23 15:47:
>> On Tuesday, 25 July 2023 15:39:25 MSK Vitaly Lipatov wrote:
>>> Alexey V. Vissarionov писал(а) 25.7.23 11:52:
>>> ...
>>>
>>> > Более того, исправить это необходимо: от пакета libpaper ожидается
>>> > собственно библиотека, а /usr/bin/paperconf и аналогичным приблудам
>>> > место в отдельном пакете - libpaper-utils или просто paperconf (они
>>> > могут требовать libpaper, но пакет libpaper их требовать не должен).
>>>
>>> Если кому-то нужен /usr/bin/paperconf, у него должно быть
>>> Requires:  /usr/bin/paperconf
>>> и название пакета значения не имеет.
>> А если не нужен? ;-)
> Я согласен, если, как Алексей ниже написал, утилита тянет много 
> внешнего и ненужного библиотеке.
>
>>> Поэтому чем обусловлена необходимость, не ясно.
>> 1. Чтобы не было файлового конфликта у любых релизов libpaper и 
>> libpaper2
>> 2. Чтоб тот, кто `apt-get install /usr/bin/paperconf` не профукал его 
>> при
>> dist-upgrtade, когда /usr/bin/paperconf сбежал в libpaper2.
> Тогда это вопрос изначально правильной упаковки. И нужно более явное 
> требование отдельной упаковки утилит в случае, если они один с 
> библиотекой.

Да, вообще если библиотека пакуется под SharedLibsPolicy, то в пакете с 
библиотекой не должно быть ничего, что может потом в дальнейшем начать 
конфликтовать с файлами из нового пакета этой библиотеки.

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

т.е. - ошибки упаковки нормально можно исправить только в момент смены 
soname.

Re: [devel] libpaper update

[Alexey V. Vissarionov]

Good ${greeting_time}!

On 2023-07-25 15:39:25 +0300, Vitaly Lipatov wrote:

 >> Более того, исправить это необходимо: от пакета libpaper
 >> ожидается собственно библиотека, а /usr/bin/paperconf и
 >> аналогичным приблудам место в отдельном пакете
 > Если кому-то нужен /usr/bin/paperconf, у него должно быть
 > Requires: /usr/bin/paperconf и название пакета значения
 > не имеет. Поэтому чем обусловлена необходимость, не ясно.

Минимизацией зависимостей пакета с библиотекой. Очень уж
неприятно бывает, когда мейнтейнер поленился упаковать
%_libdir/*.so.* отдельно, а %_bindir/* отдельно - особенно
когда в %_bindir лежит, например, скрипт на каком-нибудь,
пардон, пыхтоне, который тащит себе весь интерпретатор.
А реально при этом нужна только библиотека и только для
удовлетворения бинарной зависимости.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] libpaper update (was: [#325166] DONE (try 15) libpaper.git=2.1.1-alt1 boomaga.git=3.0.0-alt1.2 xmlto.git=0.0.28-alt3 ...)

[Vitaly Lipatov]

Gleb Fotengauer-Malinovskiy писал(а) 25.7.23 11:16:
...
> Я вот считаю, что это была довольно сложная задача.
Задача сложная, а должна быть просто, потому что это всего лишь 
обновление версии пакета, и оно не должно сопровождаться такими 
сложностями.

>> пакета со сменой
>> soname библиотеки выглядит невразумительно и неоправданно сложным
>> благодаря Shared Policy Libs.
> 
> Shared Libs Policy всегда была связана с необходимостью.  Вообще, 
> практика
> показывает, что если библиотека сразу собрана с учётом существования
> Shared Libs Policy и опыта обновления библиотек со сменой soname, то и
> обновление происходит проще.
Вообще, практика показывает, что если расставлять soname в названия 
пакетов, то обновление ещё проще происходит.
И названия пакетов не мельтешат. Возможно удивительно, что столько 
внимания к названиям пакетов библиотек. У них вообще не должно быть 
названий, их суть — это библиотеки внутри.

>> Тут даже лучше начинаешь понимать те
>> апстримы, которые делают несовместимые изменения, не меняя soname.
> 
> Я не понимаю связи.
У меня есть подозрение, что некоторым апстримам проще пойти на изменение 
ABI без смены soname, чем внести несовместимость по названию библиотеки.

...
>> Если что, libpaper был нужен для тех пакетов, которые указывали
>> Requires: libpaper ради того, чтобы получить /usr/bin/paperconf. Если 
>> вы
>> его убрали, видимо, такие пакеты лишатся нужной им команды.
> 
> Частичный Provides: это тоже неправильно.  Тут можно только исправить
> все такие пакеты.
> Вообще, эту утилиту нужно паковать отдельно, так не делалось раньше, но
Почему «нужно», вовсе не очевидно, и у меня в этом большие сомнения.

> при обновлении libpaper стоило это исправить, я даже скажу, что всё ещё
> не поздно.
Согласен, просто делать слишком много изменений сразу не очень хорошо.

...
>> > 1. Переименование бинарного пакета libpaper в libpaper1 было ошибкой
>> > потому что таким образом soname libpaper.so.1 переезжает в другой
>> > пакет.
>> А что плохого в том, что библиотека переезжает в другой пакет? 
>> Выглядит
>> как тайное знание.
> 
> https://www.altlinux.org/Shared_Libs_Policy
>   «...можно столкнуться с багофичей apt: он плохо переносит 
> переименования
>   пакетов в случае, когда содержимое старой версии пакета переносится в
>   пакет с новым именем, но при этом пакет со старым именем остаётся
>   существовать».
Это городские легенды вы цитируете. Какие-то багофичи без ссылок. Я 
вообще думаю, что apt ничего не знает о содержимом пакетов, а какие там 
названия у пакетов ему тоже всё равно, он оперирует версионированными 
именами.

>> Я вот считаю, что вообще плохо пакеты переименовывать, и бинарный
>> libpaper должен был и остаться libpaper.
> 
> Тем не менее, ты заапрувил такое переименование.
Да, из соображений симметрии, раз уж один называется libpaper2, другой 
должен быть libpaper1.

>> > 2. Между пакетами libpaper2 и libpaper < 1.1.28-alt1 отсутствовал явный
>> > конфликт, хотя эти пакеты содержат разные версии /usr/bin/paperconf.
>> +1
>> 
>> > 3. '%set_verify_elf_method rpath=relaxed' из-за попадания %_libdir в
>> > RPATH
>> > это просто стыдно, мне сложно даже как-то комментировать.
>> А кому стыдно?
> 
> К сожалению, ты аппрувишь халтуру и заметание проблем под ковёр, я 
> считаю,
> что это категорически неправильный подход для ментора.
Удобно из одной строчки про rpath делать такие обобщения. Да, я не 
заметил строчку, ну бывает.
И ментор тут ни при чём, почему бы не написать, что это неправильный 
подход для мантейнера.

>> Тому, кто не написал, почему %_libdir в RPATH это плохо
>> на странице
>> https://www.altlinux.org/ProblemWithVerifyELFAndRPATH
>> ?
> 
> Похоже, эта статья по большей части была написана вообще до появления
> проверки про стандартные пути.  Хороший повод её обновить.
Вы просто не хотите признавать, что вы наводите порядок по установленным 
правилам. Только правила эти никто не писал, они состоят из намёков, 
неоднозначностей и мнений тех, чьё мнение важнее остальных.

>> Возможно, что это я один не знаю, что такого в %_libdir в RPATH, а
>> возможно, что знает только 3 человека из Тим. Проверять будем?
> 
> Те или иные проверки rpath существуют в Альте с 2002 года, а проверка 
> на
Это не ответ на вопрос. От проверок на rpath за это время страдало много 
пакетов и мантейнеров.

> наличие стандартных каталогов с 2011 года.  Я удивлён, что ты не
> поинтересовался за столько времени, но учить кандидата в Team не
> интересоваться такими вещами это совсем другое дело.
К сожалению, запретить делать различные (в том числе и неверные) выводы 
из одного и того же факта нельзя запретить.
О каком обучении кандидата в Team речь, я не понял, видимо, это какие-то 
домыслы.

> В 2011 году при добавлении этой проверки было письмо с иллюстрацией 
> того,
> почему это плохо:
> https://lore.altlinux.org/devel/20111212145709.GE24413@altlinux.org/
Там никакая иллюстрация того, что плохо. Я согласен с аргументом про 
LD_LIBRARY_PATH (хотя он и не имеет смысла в рамках дистрибутива), но 
рассказ о том, что там как ищется при поиске библиотеки, не впечатляет.
У нас всё время такое ищется, что я каждый раз расстраиваюсь.
Мне кажется, из cat надо убрать setlocale() сначала, а потом 
рассказывать про оптимизации поиска библиотек.

Спасибо за исправление пакета и ценные замечания, конечно, все они будут 
учтены.
Но вставать в позу с рассказами о том, каким должен быть ментор, не 
нужно. Это можно делать отдельно, без перехода на личности. В первую 
очередь, формализовать хотя бы немного требования к мантейнеру и 
постараться их привезти к уровню, до которого можно дотянуться.

Нам нужна простота и понятность, а не высокоумие.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] libpaper update

[Dmitry V. Levin]

On Tue, Jul 25, 2023 at 04:12:40PM +0300, Vitaly Lipatov wrote:
[...]
> Нам нужна простота и понятность, а не высокоумие.

Для начала отучаемся говорить за всех.

Лично меня в первую очередь интересует, можно ли доверять мантейнеру
и пользоваться пакетами, которые он собирает.

Честно говоря, то, что вы написали в этом треде, говорит явно
не в вашу пользу.


-- 
ldv

[devel] доверие мантейнеру

[Vitaly Lipatov]

Dmitry V. Levin писал(а) 25.7.23 21:07:
> On Tue, Jul 25, 2023 at 04:12:40PM +0300, Vitaly Lipatov wrote:
> [...]
>> Нам нужна простота и понятность, а не высокоумие.
> 
> Для начала отучаемся говорить за всех.
Дима, вот это называется высокомерный тон. Я всё же сам решу, что и за 
кого мне говорить.
Откуда взялась идея поучать других в нетехнических вопросах? Пример 
академика Виталия Гинзбурга не самый лучший.

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

> Лично меня в первую очередь интересует, можно ли доверять мантейнеру
> и пользоваться пакетами, которые он собирает.
Есть мантейнеры, которым вполне можно доверять в их мантейнерстве, но не 
всеми пакетами можно пользоваться, например известная история с командой 
su: https://bugzilla.altlinux.org/14078 
https://bugzilla.altlinux.org/23700
а некоторые задачи (например, с ошибкой в зависимостях rpm-build) 
невозможно решить, несмотря на тривиальность решения: 
https://bugzilla.altlinux.org/34308

> Честно говоря, то, что вы написали в этом треде, говорит явно
> не в вашу пользу.
По поводу доверия думаю что не я один читал мнение Линуса Торвальдса о 
связи доверия к коду разработчиков с советско-финской войной.

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

Я бы предпочёл, чтобы мы решали насущные вопросы. Возможно, моё письмо о 
том, что в Тим нет консенсуса, прошло мимо:
https://lists.altlinux.org/pipermail/devel/2023-June/217582.html

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] доверие мантейнеру

[Dmitry V. Levin]

On Wed, Jul 26, 2023 at 02:21:13AM +0300, Vitaly Lipatov wrote:
> Dmitry V. Levin писал(а) 25.7.23 21:07:
> > On Tue, Jul 25, 2023 at 04:12:40PM +0300, Vitaly Lipatov wrote:
> > [...]
> >> Нам нужна простота и понятность, а не высокоумие.
> > 
> > Для начала отучаемся говорить за всех.
> Дима, вот это называется высокомерный тон. Я всё же сам решу, что и за 
> кого мне говорить.

Нет.  Выступать от имени другого человека имеет право только его
полномочный представитель.


-- 
ldv

Re: [devel] доверие мантейнеру

[Dmitry V. Levin]

On Wed, Jul 26, 2023 at 02:21:13AM +0300, Vitaly Lipatov wrote:
[...]
> Я бы предпочёл, чтобы мы решали насущные вопросы.

Этот тред начался с насущного вопроса, а именно, с халтуры в работе вашего
подопечного кандидата, которую вы не просто одобрили, но, очевидно,
культивируете и поощряете.  С халтуры настолько вопиющей, что об этом
пришлось написать здесь, чтобы привлечь внимание коллег, чтобы на вашем
примере показать, что неправильно делать и как нельзя поступать.

А что вы напишете, чтобы отвлечь внимание с насущного вопроса и сменить
тему, уже и не важно.


-- 
ldv

Re: [devel] доверие мантейнеру

[Vitaly Lipatov]

Dmitry V. Levin писал(а) 26.7.23 9:15:
> On Wed, Jul 26, 2023 at 02:21:13AM +0300, Vitaly Lipatov wrote:
> [...]
>> Я бы предпочёл, чтобы мы решали насущные вопросы.
> 
> Этот тред начался с насущного вопроса, а именно, с халтуры в работе 
> вашего
> подопечного кандидата, которую вы не просто одобрили, но, очевидно,
> культивируете и поощряете.  С халтуры настолько вопиющей, что об этом
> пришлось написать здесь, чтобы привлечь внимание коллег, чтобы на вашем
> примере показать, что неправильно делать и как нельзя поступать.

Чтобы было понятно, что в сборке было исправлено Глебом:

libpaper2:
-%set_verify_elf_method rpath=relaxed

-Provides: libpaper = %version-%release
-Obsoletes: libpaper <= 1.1.28
+Conflicts: libpaper < 1.1.28-alt3


libpaper:
-Group: System/Libraries
+Group: System/Legacy libraries

Что из исправленного вы называете вопиющей халтурой? А то ведь по вашим 
эмоциям можно подумать, что произошло действительно что-то ужасное.
Да, я не заметил set_verify_elf_method rpath=relaxed, бывает.
Да, группу в legacy пакете не поменяли (а с чего бы?)

Про Obsoletes -> Conflicts. Я хотел избежать появления вот этих ошибок, 
которые сейчас появились при сборке:
crtools-3.17-alt1.1:paperconf: cannot get system paper size: No such 
file or directory
zeromq-4.3.4-alt2:paperconf: cannot get system paper size: No such file 
or directory

Они вызваны пакетами, которые указали libpaper вместо /usr/bin/paperconf 
в качестве зависимости.
Их было больше, но несколько я исправил, а на остальные не хватило ACL и 
желания.

Вот проверка обновления с обсуждаемым «халтурным» заданием:
  # apt-get dist-upgrade

Следующие дополнительные пакеты будут установлены:
   libpaper-devel libpaper1 libpaper2
Следующие пакеты будут ОБНОВЛЕНЫ:
   libpaper-devel paper
Следующие пакеты будут ЗАМЕНЕНЫ:
   libpaper (by libpaper2)
Следующие НОВЫЕ пакеты будут установлены:
   libpaper1 libpaper2


При том, что в системе есть пакеты, использующие libpaper1:
  # rpm -ev libpaper
error: Failed dependencies:
	libpaper.so.1()(64bit) >= set:igEcBEf0 is needed by (installed) 
enscript-1.6.6-alt2.x86_64
	libpaper.so.1()(64bit) >= set:ihGha is needed by (installed) 
liba2ps-4.14-alt3.x86_64
	libpaper.so.1()(64bit) >= set:ieJVjgXOeLomyfkE9o5bWjy6 is needed by 
(installed) texlive-2021-alt1_2.x86_64
	libpaper.so.1()(64bit) >= set:ifZF4Qrs5jQ7 is needed by (installed) 
libgs-10.01.1-alt1.x86_64
	libpaper.so.1()(64bit) >= set:ihGha is needed by (installed) 
cups-2.4.2-alt3.x86_64
	libpaper.so.1()(64bit) >= set:ifZF4Qrs5jQ7 is needed by (installed) 
libgs9-9.54.0-alt4.x86_64
	libpaper = 1.1.28-alt1:sisyphus+278439.100.1.1 is needed by (installed) 
libpaper-devel-1.1.28-alt1.x86_64

То есть объективно повода для паники не наблюдается.

По поводу халтуры, которую я одобряю, культивирую и поощряю.
Тут вы возводите напраслину по какой-то причине.

Да, я был недостаточно внимателен в своей проверке.
Но я не одобрял халтуру в работе. Я проверил и поставил approve на 
сборку пакета. Не нужно передёргивать.

А то что вам там очевидно про культивирую и поощряю, так это просто 
вздор.
Не ожидал такого, но спасибо, что показали, как нельзя поступать.

> А что вы напишете, чтобы отвлечь внимание с насущного вопроса и сменить
> тему, уже и не важно.
Ход сильный, засчитано.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] libpaper update (was: [#325166] DONE (try 15) libpaper.git=2.1.1-alt1 boomaga.git=3.0.0-alt1.2 xmlto.git=0.0.28-alt3 ...)

[Vitaly Lipatov]

Gleb Fotengauer-Malinovskiy писал(а) 24.7.23 23:18:
...
> On Mon, Jul 24, 2023 at 06:43:10PM +0000, Girar pender (glebfm) wrote:
>> https://git.altlinux.org/tasks/archive/done/_317/325500/logs/events.3.1.log
>> #140 libpaper 2.1.1-alt1 -> 2:2.1.1-alt2
>>  Mon Jul 24 2023 Gleb F-Malinovskiy <glebfm@altlinux> 2:2.1.1-alt2
>>  - NMU:
...
>>    - libpaper2: removed the 'Provides: libpaper' because it doesn't 
>> make any
>>      sense either.
Глеб, подскажи, пожалуйста.
В Shared Libs Policy у нас написано
«Добавить в пакет libfooM Provides: libfoo = %version-%release»
Насколько я понимаю, это нужно для того, чтобы последняя версия 
библиотеки ставилась по прежнему названию:
apt-get install libpaper
и приедет libpaper2

Ты предлагаешь убрать это из Полиси или тут был какой-то особый случай?

...
> 2. Между пакетами libpaper2 и libpaper < 1.1.28-alt1 отсутствовал явный
> конфликт, хотя эти пакеты содержат разные версии /usr/bin/paperconf.
Отсутствовал в силу того, что там был Obsoletes:
-Provides: libpaper = %version-%release
-Obsoletes: libpaper <= 1.1.28
+Conflicts: libpaper < 1.1.28-alt3

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] libpaper update (was: [#325166] DONE (try 15) libpaper.git=2.1.1-alt1 boomaga.git=3.0.0-alt1.2 xmlto.git=0.0.28-alt3 ...)

[Gleb Fotengauer-Malinovskiy]

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

On Mon, Jul 31, 2023 at 06:56:27PM +0300, Vitaly Lipatov wrote:
> Gleb Fotengauer-Malinovskiy писал(а) 24.7.23 23:18:
> ...
> > On Mon, Jul 24, 2023 at 06:43:10PM +0000, Girar pender (glebfm) wrote:
> >> https://git.altlinux.org/tasks/archive/done/_317/325500/logs/events.3.1.log
> >> #140 libpaper 2.1.1-alt1 -> 2:2.1.1-alt2
> >>  Mon Jul 24 2023 Gleb F-Malinovskiy <glebfm@altlinux> 2:2.1.1-alt2
> >>  - NMU:
> ...
> >>    - libpaper2: removed the 'Provides: libpaper' because it doesn't 
> >> make any
> >>      sense either.
> Глеб, подскажи, пожалуйста.
> В Shared Libs Policy у нас написано
> «Добавить в пакет libfooM Provides: libfoo = %version-%release»
> Насколько я понимаю, это нужно для того, чтобы последняя версия 
> библиотеки ставилась по прежнему названию:
> apt-get install libpaper
> и приедет libpaper2

Это имеет смысл только если libfooN и libfooM сразу были собраны по
полиси.  Тогда от Provides: libfoo нет никакого вреда.

На мой вкус, правда, даже в этой ситуации пользы от этого крайне мало.

> Ты предлагаешь убрать это из Полиси или тут был какой-то особый случай?

Видимо, как-то уточнить.  Ну или правда, совсем убрать.

> ...
> > 2. Между пакетами libpaper2 и libpaper < 1.1.28-alt1 отсутствовал явный
> > конфликт, хотя эти пакеты содержат разные версии /usr/bin/paperconf.
> Отсутствовал в силу того, что там был Obsoletes:
> -Provides: libpaper = %version-%release
> -Obsoletes: libpaper <= 1.1.28
> +Conflicts: libpaper < 1.1.28-alt3

Да, ты прав.

-- 
glebfm

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

[devel] Re: libpaper update (was: [#325166] DONE (try 15) libpaper.git=2.1.1-alt1 boomaga.git=3.0.0-alt1.2 xmlto.git=0.0.28-alt3 ...)

[Sergey V Turchin]

On Monday, 31 July 2023 19:13:01 MSK Gleb Fotengauer wrote:

[...]
> > В Shared Libs Policy у нас написано
> > «Добавить в пакет libfooM Provides: libfoo = %version-%release»
> > Насколько я понимаю, это нужно для того, чтобы последняя версия
> > библиотеки ставилась по прежнему названию:
> > apt-get install libpaper
> > и приедет libpaper2
> 
> Это имеет смысл только если libfooN и libfooM сразу были собраны по
> полиси.  Тогда от Provides: libfoo нет никакого вреда.
> 
> На мой вкус, правда, даже в этой ситуации пользы от этого крайне мало.
А вот, от
Provides: libfoo-devel = %version
, я считаю, польза есть, если реального пакета libfoo-devel не будет.
Я зачастую просматриваю провайды у devel-пакета, если в имени цифры, чтобы 
выбрать оптимальный вариант.

[...]

-- 
Regards, Sergey.

Re: [devel] libpaper update (was: [#325166] DONE (try 15) libpaper.git=2.1.1-alt1 boomaga.git=3.0.0-alt1.2 xmlto.git=0.0.28-alt3 ...)

[Anton Farygin]

On 01.08.2023 12:30, Sergey V Turchin wrote:
> On Monday, 31 July 2023 19:13:01 MSK Gleb Fotengauer wrote:
>
> [...]
>>> В Shared Libs Policy у нас написано
>>> «Добавить в пакет libfooM Provides: libfoo = %version-%release»
>>> Насколько я понимаю, это нужно для того, чтобы последняя версия
>>> библиотеки ставилась по прежнему названию:
>>> apt-get install libpaper
>>> и приедет libpaper2
>> Это имеет смысл только если libfooN и libfooM сразу были собраны по
>> полиси.  Тогда от Provides: libfoo нет никакого вреда.
>>
>> На мой вкус, правда, даже в этой ситуации пользы от этого крайне мало.
> А вот, от
> Provides: libfoo-devel = %version
Только мне кажется что лучше EVR а не version.
> , я считаю, польза есть, если реального пакета libfoo-devel не будет.
> Я зачастую просматриваю провайды у devel-пакета, если в имени цифры, чтобы
> выбрать оптимальный вариант.
>
> [...]
>

[devel] Re: libpaper update (was: [#325166] DONE (try 15) libpaper.git=2.1.1-alt1 boomaga.git=3.0.0-alt1.2 xmlto.git=0.0.28-alt3 ...)

[Sergey V Turchin]

On Tuesday, 1 August 2023 15:06:56 MSK Anton Farygin wrote:

[...]
> > А вот, от
> > Provides: libfoo-devel = %version
> Только мне кажется что лучше EVR а не version.
Если хоть один из провайдящих пакетов так сделает, то придётся и остальным, 
иначе и так будет нормально.

> > , я считаю, польза есть

-- 
Regards, Sergey.

Re: [devel] libpaper update (was: [#325166] DONE (try 15) libpaper.git=2.1.1-alt1 boomaga.git=3.0.0-alt1.2 xmlto.git=0.0.28-alt3 ...)

[Vitaly Lipatov]

Sergey V Turchin писал(а) 1.8.23 12:30:
> On Monday, 31 July 2023 19:13:01 MSK Gleb Fotengauer wrote:
> 
> [...]
>> > В Shared Libs Policy у нас написано
>> > «Добавить в пакет libfooM Provides: libfoo = %version-%release»
>> > Насколько я понимаю, это нужно для того, чтобы последняя версия
>> > библиотеки ставилась по прежнему названию:
>> > apt-get install libpaper
>> > и приедет libpaper2
>> 
>> Это имеет смысл только если libfooN и libfooM сразу были собраны по
>> полиси.  Тогда от Provides: libfoo нет никакого вреда.
>> 
>> На мой вкус, правда, даже в этой ситуации пользы от этого крайне мало.
> А вот, от
> Provides: libfoo-devel = %version
> , я считаю, польза есть, если реального пакета libfoo-devel не будет.
> Я зачастую просматриваю провайды у devel-пакета, если в имени цифры, 
> чтобы
> выбрать оптимальный вариант.
Это наводит на мысль, что никакого смысла устанавливать пакеты библиотек 
по имени нет. В то время как devel-пакет обычно (особенно вручную) 
устанавливают по имени.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

[devel] Re: libpaper update (was: [#325166] DONE (try 15) libpaper.git=2.1.1-alt1 boomaga.git=3.0.0-alt1.2 xmlto.git=0.0.28-alt3 ...)

[Sergey V Turchin]

On Wednesday, 2 August 2023 03:44:54 MSK Vitaly Lipatov wrote:

[...]
> Это наводит на мысль, что никакого смысла устанавливать пакеты библиотек
> по имени нет. В то время как devel-пакет обычно (особенно вручную)
> устанавливают по имени.
Есть, но в "неправильных" случаях. Когда они содержат необходимые файлы, 
которых там не должно быть по хорошему, а красивого provide-а на них нет. 
Плагин или ещё что. Например, libqt5-multimedia сравните с qt6-multimedia, у 
которых ещё и борода зависимостей.

P.S.
У libqt5-multimedia красивый qml-provide есть, но кто ж смотрит. ;-)

-- 
Regards, Sergey.