[devel] libglusterfs6: shlib policy issue

[devel] libglusterfs6: shlib policy issue

[Vladimir D. Seleznev]

Сонеймы, предоставляемые libglusterfs3, не поменялись. Зачем тогда надо
было переименовывать [1] пакет?

Если строго следовать shlib policy [2], то %abiversion должен быть равен
нулю (а если совсем строго, то каждую shared library следует класть в
свой подпакет).

[1] https://lists.altlinux.org/pipermail/sisyphus-incominger/2019-June/533382.html
[2] https://www.altlinux.org/Shared_Libs_Policy

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

Re: [devel] libglusterfs6: shlib policy issue

[Ivan Zakharyaschev]

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

Hello!

On Sat, 15 Jun 2019, Vladimir D. Seleznev wrote:

> Сонеймы, предоставляемые libglusterfs3, не поменялись. Зачем тогда надо
> было переименовывать [1] пакет?

Да, они ещё пересекаются по файлам, а Conflicts не стоит. Поэтому, когда я 
тестировал недавно dist-upgrade, транзакция сваливалась (помимо симлинка в 
gdb https://bugzilla.altlinux.org/show_bug.cgi?id=35492 ).

$ comm -1 -2 <(rpm -qp /ALT/Sisyphus/x86_64/RPMS.classic/libglusterfs3-3.12.15-alt3.x86_64.rpm -l) <(rpm -qp /ALT/Sisyphus/x86_64/RPMS.classic/libglusterfs6-6.2-alt1.x86_64.rpm -l)
/usr/lib/glusterfs
/usr/lib64/glusterfs
/usr/lib64/libgfchangelog.so.0
/usr/lib64/libgfchangelog.so.0.0.1
/usr/lib64/libgfrpc.so.0
/usr/lib64/libgfrpc.so.0.0.1
/usr/lib64/libgfxdr.so.0
/usr/lib64/libgfxdr.so.0.0.1
/usr/lib64/libglusterfs.so.0
/usr/lib64/libglusterfs.so.0.0.1
/usr/share/glusterfs
$ rpm -qp /ALT/Sisyphus/x86_64/RPMS.classic/libglusterfs3-3.12.15-alt3.x86_64.rpm /ALT/Sisyphus/x86_64/RPMS.classic/libglusterfs6-6.2-alt1.x86_64.rpm --conflicts
$ 


-- 
Best regards,
Ivan

Re: [devel] libglusterfs6: shlib policy issue

[Ivan Zakharyaschev]

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


On Sat, 15 Jun 2019, Ivan Zakharyaschev wrote:

> On Sat, 15 Jun 2019, Vladimir D. Seleznev wrote:
> 
> > Сонеймы, предоставляемые libglusterfs3, не поменялись. Зачем тогда надо
> > было переименовывать [1] пакет?
> 
> Да, они ещё пересекаются по файлам, а Conflicts не стоит. Поэтому, когда я 
> тестировал недавно dist-upgrade, транзакция сваливалась (помимо симлинка в 
> gdb https://bugzilla.altlinux.org/show_bug.cgi?id=35492 ).
> 
> $ comm -1 -2 <(rpm -qp /ALT/Sisyphus/x86_64/RPMS.classic/libglusterfs3-3.12.15-alt3.x86_64.rpm -l) <(rpm -qp /ALT/Sisyphus/x86_64/RPMS.classic/libglusterfs6-6.2-alt1.x86_64.rpm -l)
> /usr/lib/glusterfs
> /usr/lib64/glusterfs
> /usr/lib64/libgfchangelog.so.0
> /usr/lib64/libgfchangelog.so.0.0.1
> /usr/lib64/libgfrpc.so.0
> /usr/lib64/libgfrpc.so.0.0.1
> /usr/lib64/libgfxdr.so.0
> /usr/lib64/libgfxdr.so.0.0.1
> /usr/lib64/libglusterfs.so.0
> /usr/lib64/libglusterfs.so.0.0.1
> /usr/share/glusterfs
> $ rpm -qp /ALT/Sisyphus/x86_64/RPMS.classic/libglusterfs3-3.12.15-alt3.x86_64.rpm /ALT/Sisyphus/x86_64/RPMS.classic/libglusterfs6-6.2-alt1.x86_64.rpm --conflicts
> $ 

В libglusterfs6-6.3-alt2.x86_64.rpm это исправили, там есть Conflicts:

libglusterfs3

-- 
Best regards,
Ivan

Re: [devel] libglusterfs6: shlib policy issue

[Vladimir D. Seleznev]

On Sat, Jun 15, 2019 at 01:56:26PM +0300, Vitaly Lipatov wrote:
> On Sat, 15 Jun 2019, Vladimir D. Seleznev wrote:
> 
> > Сонеймы, предоставляемые libglusterfs3, не поменялись. Зачем тогда надо
> > было переименовывать [1] пакет?
> 
> Пакет никто не переименовывал.  Просто новая мажорная версия собрана в
> свой набор пакетов, чтобы не произошло автоматического обновления,
> которое недопустимо для системы хранения данных. 
> 
> Alexey Shabalin писал 15.6.19 2:38:
> 
> > ... 
> > Пока andy@ готовил пакет glusterfs, с provides и obsoletes, в Сизифе
> > появился glustetfs6. Поэтому мы решили не выкладывать его, а немного
> > доделать. А вообще бы хорошо убрать эти 3 и 6 из имени.
> 
> Не очень понятно, зачем нужно было при живом мантейнере glusterfs
> готовить какой-то альтернативный пакет, и никак не информировать. Если
> кто-то может заняться гластером, я с радостью перестану тянуть (и
> тестировать и эксплуатировать) эту достаточно тяжёлую ношу. 
> 
> Про 3 и 6 в имени уже написал выше -- обновления не предусматривается. 

Т.е., тут такой же случай, как и с PostgreSQL? Неправильно, что один и
тот же сонейм в репозитории предоставляют разные пакеты. Т.к. glusterfs3
и glusterfs6 предоставляют в своих библиотеках одинаковый ABI + новый
ABI в glusterfs6, то надо, чтобы в репозитории были представлены
разделяемые библиотеки от glusterfs6, а в glusterfs3 не собирать
разделяемых библиотек. Тогда будут и два пакета, что позволит и
поддерживать уже имеющиеся решения на glusterfs3, и будут предоставлены
актуальные библиотеки, пакеты которых таки лучше привести в соответствие
Shared library policy.

> Пример того, что бывает, когда в рамках одного названия пакета
> происходят несовместимые обновления: 
> 
> https://bugzilla.altlinux.org/show_bug.cgi?id=36901 


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

Re: [devel] libglusterfs6: shlib policy issue

[Dmitry V. Levin]

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

On Sat, Jun 15, 2019 at 10:43:58PM +0300, Vladimir D. Seleznev wrote:
> On Sat, Jun 15, 2019 at 01:56:26PM +0300, Vitaly Lipatov wrote:
> > On Sat, 15 Jun 2019, Vladimir D. Seleznev wrote:
> > 
> > > Сонеймы, предоставляемые libglusterfs3, не поменялись. Зачем тогда надо
> > > было переименовывать [1] пакет?
> > 
> > Пакет никто не переименовывал.  Просто новая мажорная версия собрана в
> > свой набор пакетов, чтобы не произошло автоматического обновления,
> > которое недопустимо для системы хранения данных. 
> > 
> > Alexey Shabalin писал 15.6.19 2:38:
> > 
> > > ... 
> > > Пока andy@ готовил пакет glusterfs, с provides и obsoletes, в Сизифе
> > > появился glustetfs6. Поэтому мы решили не выкладывать его, а немного
> > > доделать. А вообще бы хорошо убрать эти 3 и 6 из имени.
> > 
> > Не очень понятно, зачем нужно было при живом мантейнере glusterfs
> > готовить какой-то альтернативный пакет, и никак не информировать. Если
> > кто-то может заняться гластером, я с радостью перестану тянуть (и
> > тестировать и эксплуатировать) эту достаточно тяжёлую ношу. 
> > 
> > Про 3 и 6 в имени уже написал выше -- обновления не предусматривается. 
> 
> Т.е., тут такой же случай, как и с PostgreSQL? Неправильно, что один и
> тот же сонейм в репозитории предоставляют разные пакеты. Т.к. glusterfs3
> и glusterfs6 предоставляют в своих библиотеках одинаковый ABI + новый
> ABI в glusterfs6, то надо, чтобы в репозитории были представлены
> разделяемые библиотеки от glusterfs6, а в glusterfs3 не собирать
> разделяемых библиотек. Тогда будут и два пакета, что позволит и
> поддерживать уже имеющиеся решения на glusterfs3, и будут предоставлены
> актуальные библиотеки, пакеты которых таки лучше привести в соответствие
> Shared library policy.

Вывод команды
$ rpmsodiff libglusterfs3-3.12.15-alt3.x86_64.rpm libglusterfs6-6.3-alt2.x86_64.rpm
наводит на мысль, что у библиотек должны были поменяться soname.

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


-- 
ldv

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

[devel] I: alternative soname implementations considered harmful

[Dmitry V. Levin]

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

On Sun, Jun 16, 2019 at 12:20:50AM +0300, Dmitry V. Levin wrote:
> Я всё-таки склоняюсь к мысли, что альтернативные реализации одного soname
> в рамках репозитория следует запретить.  Сейчас в Сизифе 18 таких soname.

Таким образом, под запрет попадут следующие пакеты:

$ xzcat Sisyphus/x86_64/base/pkglist.classic.xz |pkglist-query '[%{=sourcerpm}\t%{=name}\t%{providename} %{provideflags:depflags} %{provideversion}\n]' /dev/stdin |sed -n 's/^\([^[:space:]]\+\)[[:space:]]\+\([^[:space:]]\+\)[[:space:]]\+\(lib[^ ()]\+\)()(64bit) = set:.*/\1\t\2\t\3/p' |sort -k3,3 |uniq -D -f2

aufs2-util-2.2-alt0.1.src.rpm	aufs2-util	libau.so.2
aufs3-util-3.0-alt0.1.src.rpm	aufs3-util	libau.so.2
gcc5-5.3.1-alt6.src.rpm	gcc5-gdb-plugin	libcc1.so.0
gcc6-6.3.1-alt4.src.rpm	gcc6-gdb-plugin	libcc1.so.0
gcc7-7.3.1-alt9.src.rpm	gcc7-gdb-plugin	libcc1.so.0
gcc8-8.3.1-alt3.src.rpm	gcc8-gdb-plugin	libcc1.so.0
cgns-mpi-3.2-alt3.svn20150317.src.rpm	libcgns-mpi	libcgns.so.3.2
cgns-seq-3.2-alt4.svn20150317.src.rpm	libcgns-seq	libcgns.so.3.2
glusterfs3-3.12.15-alt3.src.rpm	libglusterfs3-api	libgfapi.so.0
glusterfs6-6.3-alt2.src.rpm	libglusterfs6-api	libgfapi.so.0
glusterfs3-3.12.15-alt3.src.rpm	libglusterfs3	libgfchangelog.so.0
glusterfs6-6.3-alt2.src.rpm	libglusterfs6	libgfchangelog.so.0
glusterfs3-3.12.15-alt3.src.rpm	libglusterfs3	libgfrpc.so.0
glusterfs6-6.3-alt2.src.rpm	libglusterfs6	libgfrpc.so.0
glusterfs3-3.12.15-alt3.src.rpm	libglusterfs3	libgfxdr.so.0
glusterfs6-6.3-alt2.src.rpm	libglusterfs6	libgfxdr.so.0
glusterfs3-3.12.15-alt3.src.rpm	libglusterfs3	libglusterfs.so.0
glusterfs6-6.3-alt2.src.rpm	libglusterfs6	libglusterfs.so.0
libhdf5-8-mpi-1.8.13-alt4.src.rpm	libhdf5-8-mpi	libhdf5.so.8
libhdf5-8-seq-1.8.13-alt1.qa4.src.rpm	libhdf5-8-seq	libhdf5.so.8
libhdf5-8-mpi-1.8.13-alt4.src.rpm	libhdf5-8-mpi	libhdf5_hl.so.8
libhdf5-8-seq-1.8.13-alt1.qa4.src.rpm	libhdf5-8-seq	libhdf5_hl.so.8
libixp-0.5-alt1.qa1.src.rpm	libixp	libixp.so.0
libixp0-0.3-alt1.src.rpm	libixp0	libixp.so.0
LibreOffice-6.2.4.2-alt1.src.rpm	libreofficekit	liblibreofficekitgtk.so
LibreOffice-still-6.1.6.3-alt3.src.rpm	libreofficekit-still	liblibreofficekitgtk.so
libnetcdf11-mpi-4.4.1.1-alt2.src.rpm	libnetcdf11-mpi	libnetcdf.so.11
libnetcdf11-seq-4.4.1.1-alt3.src.rpm	libnetcdf11-seq	libnetcdf.so.11
libnetcdf_c++-4-mpi-4.2-alt4.src.rpm	libnetcdf_c++-4-mpi	libnetcdf_c++.so.4
libnetcdf_c++-4-seq-4.2-alt3.src.rpm	libnetcdf_c++-4-seq	libnetcdf_c++.so.4
libnetcdf_c++4-1-mpi-4.3.0-alt1.src.rpm	libnetcdf_c++4-1-mpi	libnetcdf_c++4.so.1
libnetcdf_c++4-1-seq-4.3.0-alt1.src.rpm	libnetcdf_c++4-1-seq	libnetcdf_c++4.so.1
libnetcdff6-mpi-4.4.4-alt1.src.rpm	libnetcdff6-mpi	libnetcdff.so.6
libnetcdff6-seq-4.4.4-alt1.src.rpm	libnetcdff6-seq	libnetcdff.so.6
thrift-0.10.0-alt5_15jpp8.src.rpm	thrift-devel	libthrift_c_glib.so.0
thrift-0.10.0-alt5_15jpp8.src.rpm	thrift-glib	libthrift_c_glib.so.0
samba-4.10.3-alt3.src.rpm	libwbclient	libwbclient.so.0
sssd-2.1.0-alt1.src.rpm	libwbclient-sssd	libwbclient.so.0
wine-4.10.1-alt1.src.rpm	libwine	libwine.so.1
wine-vanilla-4.10-alt1.src.rpm	libwine-vanilla	libwine.so.1

thrift-devel и thrift-glib - это не альтернативные реализации,
а https://bugzilla.altlinux.org/36905, но под запрет они тоже попадут.


-- 
ldv

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

Re: [devel] I: alternative soname implementations considered harmful

[Dmitry V. Levin]

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

On Mon, Jun 17, 2019 at 05:51:55PM +0300, Dmitry V. Levin wrote:
> On Sun, Jun 16, 2019 at 12:20:50AM +0300, Dmitry V. Levin wrote:
> > Я всё-таки склоняюсь к мысли, что альтернативные реализации одного soname
> > в рамках репозитория следует запретить.  Сейчас в Сизифе 18 таких soname.
> 
> Таким образом, под запрет попадут следующие пакеты:
> 
> $ xzcat Sisyphus/x86_64/base/pkglist.classic.xz |pkglist-query '[%{=sourcerpm}\t%{=name}\t%{providename} %{provideflags:depflags} %{provideversion}\n]' /dev/stdin |sed -n 's/^\([^[:space:]]\+\)[[:space:]]\+\([^[:space:]]\+\)[[:space:]]\+\(lib[^ ()]\+\)()(64bit) = set:.*/\1\t\2\t\3/p' |sort -k3,3 |uniq -D -f2
> 
> aufs2-util-2.2-alt0.1.src.rpm	aufs2-util	libau.so.2
> aufs3-util-3.0-alt0.1.src.rpm	aufs3-util	libau.so.2
> gcc5-5.3.1-alt6.src.rpm	gcc5-gdb-plugin	libcc1.so.0
> gcc6-6.3.1-alt4.src.rpm	gcc6-gdb-plugin	libcc1.so.0
> gcc7-7.3.1-alt9.src.rpm	gcc7-gdb-plugin	libcc1.so.0
> gcc8-8.3.1-alt3.src.rpm	gcc8-gdb-plugin	libcc1.so.0
> cgns-mpi-3.2-alt3.svn20150317.src.rpm	libcgns-mpi	libcgns.so.3.2
> cgns-seq-3.2-alt4.svn20150317.src.rpm	libcgns-seq	libcgns.so.3.2
> glusterfs3-3.12.15-alt3.src.rpm	libglusterfs3-api	libgfapi.so.0
> glusterfs6-6.3-alt2.src.rpm	libglusterfs6-api	libgfapi.so.0
> glusterfs3-3.12.15-alt3.src.rpm	libglusterfs3	libgfchangelog.so.0
> glusterfs6-6.3-alt2.src.rpm	libglusterfs6	libgfchangelog.so.0
> glusterfs3-3.12.15-alt3.src.rpm	libglusterfs3	libgfrpc.so.0
> glusterfs6-6.3-alt2.src.rpm	libglusterfs6	libgfrpc.so.0
> glusterfs3-3.12.15-alt3.src.rpm	libglusterfs3	libgfxdr.so.0
> glusterfs6-6.3-alt2.src.rpm	libglusterfs6	libgfxdr.so.0
> glusterfs3-3.12.15-alt3.src.rpm	libglusterfs3	libglusterfs.so.0
> glusterfs6-6.3-alt2.src.rpm	libglusterfs6	libglusterfs.so.0
> libhdf5-8-mpi-1.8.13-alt4.src.rpm	libhdf5-8-mpi	libhdf5.so.8
> libhdf5-8-seq-1.8.13-alt1.qa4.src.rpm	libhdf5-8-seq	libhdf5.so.8
> libhdf5-8-mpi-1.8.13-alt4.src.rpm	libhdf5-8-mpi	libhdf5_hl.so.8
> libhdf5-8-seq-1.8.13-alt1.qa4.src.rpm	libhdf5-8-seq	libhdf5_hl.so.8
> libixp-0.5-alt1.qa1.src.rpm	libixp	libixp.so.0
> libixp0-0.3-alt1.src.rpm	libixp0	libixp.so.0
> LibreOffice-6.2.4.2-alt1.src.rpm	libreofficekit	liblibreofficekitgtk.so
> LibreOffice-still-6.1.6.3-alt3.src.rpm	libreofficekit-still	liblibreofficekitgtk.so
> libnetcdf11-mpi-4.4.1.1-alt2.src.rpm	libnetcdf11-mpi	libnetcdf.so.11
> libnetcdf11-seq-4.4.1.1-alt3.src.rpm	libnetcdf11-seq	libnetcdf.so.11
> libnetcdf_c++-4-mpi-4.2-alt4.src.rpm	libnetcdf_c++-4-mpi	libnetcdf_c++.so.4
> libnetcdf_c++-4-seq-4.2-alt3.src.rpm	libnetcdf_c++-4-seq	libnetcdf_c++.so.4
> libnetcdf_c++4-1-mpi-4.3.0-alt1.src.rpm	libnetcdf_c++4-1-mpi	libnetcdf_c++4.so.1
> libnetcdf_c++4-1-seq-4.3.0-alt1.src.rpm	libnetcdf_c++4-1-seq	libnetcdf_c++4.so.1
> libnetcdff6-mpi-4.4.4-alt1.src.rpm	libnetcdff6-mpi	libnetcdff.so.6
> libnetcdff6-seq-4.4.4-alt1.src.rpm	libnetcdff6-seq	libnetcdff.so.6
> thrift-0.10.0-alt5_15jpp8.src.rpm	thrift-devel	libthrift_c_glib.so.0
> thrift-0.10.0-alt5_15jpp8.src.rpm	thrift-glib	libthrift_c_glib.so.0
> samba-4.10.3-alt3.src.rpm	libwbclient	libwbclient.so.0
> sssd-2.1.0-alt1.src.rpm	libwbclient-sssd	libwbclient.so.0
> wine-4.10.1-alt1.src.rpm	libwine	libwine.so.1
> wine-vanilla-4.10-alt1.src.rpm	libwine-vanilla	libwine.so.1
> 
> thrift-devel и thrift-glib - это не альтернативные реализации,
> а https://bugzilla.altlinux.org/36905, но под запрет они тоже попадут.

Дополнительно обращаю внимание мантейнеров вышеперечисленных пакетов.


-- 
ldv

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

Re: [devel] I: alternative soname implementations considered harmful

[Vitaly Lipatov]

Dmitry V. Levin писал 19.6.19 0:30:
> On Mon, Jun 17, 2019 at 05:51:55PM +0300, Dmitry V. Levin wrote:
>> On Sun, Jun 16, 2019 at 12:20:50AM +0300, Dmitry V. Levin wrote:
>> > Я всё-таки склоняюсь к мысли, что альтернативные реализации одного soname
>> > в рамках репозитория следует запретить.  Сейчас в Сизифе 18 таких soname.

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

...
>> gcc5-5.3.1-alt6.src.rpm	gcc5-gdb-plugin	libcc1.so.0
>> gcc6-6.3.1-alt4.src.rpm	gcc6-gdb-plugin	libcc1.so.0
>> gcc7-7.3.1-alt9.src.rpm	gcc7-gdb-plugin	libcc1.so.0
>> gcc8-8.3.1-alt3.src.rpm	gcc8-gdb-plugin	libcc1.so.0
Надеюсь, цифры уберём и у нас будет один gcc :)


>> wine-4.10.1-alt1.src.rpm	libwine	libwine.so.1
>> wine-vanilla-4.10-alt1.src.rpm	libwine-vanilla	libwine.so.1
Что мне кажется, что тут коса на камень.


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

Re: [devel] I: alternative soname implementations considered harmful

[Vladimir D. Seleznev]

On Wed, Jun 19, 2019 at 09:33:56AM +0300, Vitaly Lipatov wrote:
> Dmitry V. Levin писал 19.6.19 0:30:
> > On Mon, Jun 17, 2019 at 05:51:55PM +0300, Dmitry V. Levin wrote:
> >> On Sun, Jun 16, 2019 at 12:20:50AM +0300, Dmitry V. Levin wrote:
> >> > Я всё-таки склоняюсь к мысли, что альтернативные реализации одного soname
> >> > в рамках репозитория следует запретить.  Сейчас в Сизифе 18 таких soname.
> 
> Так а аргументы будут?

https://lists.altlinux.org/pipermail/devel/2019-June/208053.html

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

Использование разных soname'ов.

> ...
> >> gcc5-5.3.1-alt6.src.rpm	gcc5-gdb-plugin	libcc1.so.0
> >> gcc6-6.3.1-alt4.src.rpm	gcc6-gdb-plugin	libcc1.so.0
> >> gcc7-7.3.1-alt9.src.rpm	gcc7-gdb-plugin	libcc1.so.0
> >> gcc8-8.3.1-alt3.src.rpm	gcc8-gdb-plugin	libcc1.so.0
> Надеюсь, цифры уберём и у нас будет один gcc :)

Они вообще не предоставляют никаких soname'ов.

> >> wine-4.10.1-alt1.src.rpm	libwine	libwine.so.1
> >> wine-vanilla-4.10-alt1.src.rpm	libwine-vanilla	libwine.so.1
> Что мне кажется, что тут коса на камень.

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

Re: [devel] I: alternative soname implementations considered harmful

[Dmitry V. Levin]

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

On Wed, Jun 19, 2019 at 09:33:56AM +0300, Vitaly Lipatov wrote:
> Dmitry V. Levin писал 19.6.19 0:30:
> > On Mon, Jun 17, 2019 at 05:51:55PM +0300, Dmitry V. Levin wrote:
> >> On Sun, Jun 16, 2019 at 12:20:50AM +0300, Dmitry V. Levin wrote:
> >> > Я всё-таки склоняюсь к мысли, что альтернативные реализации одного soname
> >> > в рамках репозитория следует запретить.  Сейчас в Сизифе 18 таких soname.
> 
> Так а аргументы будут?
> Точнее, каковы будут механизмы запрета и механизмы исключения из 
> запрета.

Делать разные soname.

> ...
> >> gcc5-5.3.1-alt6.src.rpm	gcc5-gdb-plugin	libcc1.so.0
> >> gcc6-6.3.1-alt4.src.rpm	gcc6-gdb-plugin	libcc1.so.0
> >> gcc7-7.3.1-alt9.src.rpm	gcc7-gdb-plugin	libcc1.so.0
> >> gcc8-8.3.1-alt3.src.rpm	gcc8-gdb-plugin	libcc1.so.0
> Надеюсь, цифры уберём и у нас будет один gcc :)

Здесь всё ещё проще: поскольку gdb использует libcc1.so с помощью dlopen,
libcc1.so.0 вообще не нужен.

> >> wine-4.10.1-alt1.src.rpm	libwine	libwine.so.1
> >> wine-vanilla-4.10-alt1.src.rpm	libwine-vanilla	libwine.so.1
> Что мне кажется, что тут коса на камень.

Так они же ещё и разные:

$ rpmsodiff libwine-vanilla-4.10-alt1.x86_64.rpm libwine-4.10.1-alt1.x86_64.rpm
	common sonames:
libwine.so.1	/usr/lib64/libwine.so.1.0	/usr/lib64/libwine.so.1.0

--- libwine-vanilla-4.10-alt1/libwine.so.1	2019-06-10 23:56:15.000000000 +0300
+++ libwine-4.10.1-alt1/libwine.so.1	2019-06-11 20:12:18.000000000 +0300
@@ -65,2 +65,3 @@
 wine_dbgstr_wn	T
+wine_dladdr	T
 wine_dlclose	T
@@ -80,2 +81,4 @@
 wine_get_data_dir	T
+wine_get_libs	T
+wine_get_patches	T
 wine_get_server_dir	T

	3 symbols added
T wine_dladdr
T wine_get_libs
T wine_get_patches

$ apt-cache showpkg 'libwine.so.1()(64bit)'
Package: libwine.so.1()(64bit)
Versions: 

Reverse Depends: 
  wine-grdwine,libwine.so.1()(64bit) set:kikzKTTOo11
  dssi-vst,libwine.so.1()(64bit) set:kikzKTTOo11
Dependencies: 
Provides: 
Reverse Provides: 
libwine-vanilla 4.10-alt1@1560199706
libwine 1:4.10.1-alt1@1560272474

Каким образом клиенты libwine.so.1 будут выбирать нужную реализацию?


-- 
ldv

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

Re: [devel] I: alternative soname implementations considered harmful

[Andrey Savchenko]

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

On Wed, 19 Jun 2019 10:25:13 +0300 Dmitry V. Levin wrote:
> > >> wine-4.10.1-alt1.src.rpm	libwine	libwine.so.1
> > >> wine-vanilla-4.10-alt1.src.rpm	libwine-vanilla	libwine.so.1
> > Что мне кажется, что тут коса на камень.
> 
> Так они же ещё и разные:

Да, они разные. Т.к. есть сильно разные реализации wine, в т.ч.
патченая и ванильная. В других дистрибутивах так же. Людям нужны
разные wine, т.к., к примеру, одним игрушки нужны, а другим —
офисное ПО.

> Каким образом клиенты libwine.so.1 будут выбирать нужную реализацию?

Я стесняюсь спросить, а они есть вообще?

Кстати, а как у нас решается проблема с libressl vs openssl? Есть
же те, кому только libressl подавай и их число будет расти? Если
я правильно понимаю архитектуру нашей сборки, то единственный выход
— собирать статикой.

Может, и с нынешними конфликтами так поступить, выбрав "основную"
реализацию, которой можно будет .so предоставлять?

Best regards,
Andrew Savchenko

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

Re: [devel] I: alternative soname implementations considered harmful

[Dmitry V. Levin]

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

On Wed, Jun 19, 2019 at 02:10:30PM +0300, Andrey Savchenko wrote:
> On Wed, 19 Jun 2019 10:25:13 +0300 Dmitry V. Levin wrote:
> > > >> wine-4.10.1-alt1.src.rpm	libwine	libwine.so.1
> > > >> wine-vanilla-4.10-alt1.src.rpm	libwine-vanilla	libwine.so.1
> > > Что мне кажется, что тут коса на камень.
> > 
> > Так они же ещё и разные:
> 
> Да, они разные. Т.к. есть сильно разные реализации wine, в т.ч.
> патченая и ванильная. В других дистрибутивах так же. Людям нужны
> разные wine, т.к., к примеру, одним игрушки нужны, а другим —
> офисное ПО.

libwine - это ещё не wine.

> > Каким образом клиенты libwine.so.1 будут выбирать нужную реализацию?
> 
> Я стесняюсь спросить, а они есть вообще?

Я же процитировал:

Reverse Depends:
  wine-grdwine,libwine.so.1()(64bit) set:kikzKTTOo11
  dssi-vst,libwine.so.1()(64bit) set:kikzKTTOo11

> Кстати, а как у нас решается проблема с libressl vs openssl? Есть

У них soname разные:

$ rpmquery --provides -p libcrypto1.1-1.1.1b-alt2.x86_64.rpm |sed -n '/ = set:.*/ s///p'
libcrypto.so.1.1()(64bit)

$ rpmquery --provides -p libcrypto-LibreSSL-2.9.2-alt1.x86_64.rpm |sed -n '/ = set:.*/ s///p'
libcrypto.so.45()(64bit)


-- 
ldv

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

Re: [devel] I: alternative soname implementations considered harmful

[Vitaly Lipatov]

Dmitry V. Levin писал 19.6.19 14:21:
...
> libwine - это ещё не wine.
> 
>> > Каким образом клиенты libwine.so.1 будут выбирать нужную реализацию?
>> 
>> Я стесняюсь спросить, а они есть вообще?
> 
> Я же процитировал:
> 
> Reverse Depends:
>   wine-grdwine,libwine.so.1()(64bit) set:kikzKTTOo11
>   dssi-vst,libwine.so.1()(64bit) set:kikzKTTOo11

Клиентам всё равно, какой wine.



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

Re: [devel] I: alternative soname implementations considered harmful

[Sergey V Turchin]

On Wednesday, 19 June 2019 14:10:30 MSK Andrey Savchenko wrote:

[...]
> Кстати, а как у нас решается проблема с libressl vs openssl?
Например, сборкой с чем-то одним. Один модуль pam в sddm не работал и его 
пришлось пересобрать с libssl.

[...]

-- 
Regards, Sergey.

Re: [devel] I: alternative soname implementations considered harmful

[Anton Farygin]

On 17.06.2019 17:51, Dmitry V. Levin wrote:
> On Sun, Jun 16, 2019 at 12:20:50AM +0300, Dmitry V. Levin wrote:
>> Я всё-таки склоняюсь к мысли, что альтернативные реализации одного soname
>> в рамках репозитория следует запретить.  Сейчас в Сизифе 18 таких soname.
> Таким образом, под запрет попадут следующие пакеты:
>
> $ xzcat Sisyphus/x86_64/base/pkglist.classic.xz |pkglist-query '[%{=sourcerpm}\t%{=name}\t%{providename} %{provideflags:depflags} %{provideversion}\n]' /dev/stdin |sed -n 's/^\([^[:space:]]\+\)[[:space:]]\+\([^[:space:]]\+\)[[:space:]]\+\(lib[^ ()]\+\)()(64bit) = set:.*/\1\t\2\t\3/p' |sort -k3,3 |uniq -D -f2

Помимо предоставления одного soname разными библиотеками было бы отлично 
ещё научиться бороться вот с этим:
https://bugzilla.altlinux.org/show_bug.cgi?id=36925

В принципе одного поля ягода.

Re: [devel] libglusterfs6: shlib policy issue

[Vitaly Lipatov]

Vladimir D. Seleznev писал 15.6.19 22:43:
> On Sat, Jun 15, 2019 at 01:56:26PM +0300, Vitaly Lipatov wrote:
>> On Sat, 15 Jun 2019, Vladimir D. Seleznev wrote:
>> 
>> > Сонеймы, предоставляемые libglusterfs3, не поменялись. Зачем тогда надо
>> > было переименовывать [1] пакет?
>> 
>> Пакет никто не переименовывал.  Просто новая мажорная версия собрана в
>> свой набор пакетов, чтобы не произошло автоматического обновления,
>> которое недопустимо для системы хранения данных.
>> 
>> Alexey Shabalin писал 15.6.19 2:38:
>> 
>> > ...
>> > Пока andy@ готовил пакет glusterfs, с provides и obsoletes, в Сизифе
>> > появился glustetfs6. Поэтому мы решили не выкладывать его, а немного
>> > доделать. А вообще бы хорошо убрать эти 3 и 6 из имени.
>> 
>> Не очень понятно, зачем нужно было при живом мантейнере glusterfs
>> готовить какой-то альтернативный пакет, и никак не информировать. Если
>> кто-то может заняться гластером, я с радостью перестану тянуть (и
>> тестировать и эксплуатировать) эту достаточно тяжёлую ношу.
>> 
>> Про 3 и 6 в имени уже написал выше -- обновления не предусматривается.
> 
> Т.е., тут такой же случай, как и с PostgreSQL? Неправильно, что один и
> тот же сонейм в репозитории предоставляют разные пакеты. Т.к. 
> glusterfs3
Почему неправильно?

> и glusterfs6 предоставляют в своих библиотеках одинаковый ABI + новый
> ABI в glusterfs6, то надо, чтобы в репозитории были представлены
Нет информации, что они там предоставляют. И я бы точно не стал 
смешивать клиентов разных версий.

> разделяемые библиотеки от glusterfs6, а в glusterfs3 не собирать
> разделяемых библиотек. Тогда будут и два пакета, что позволит и
> поддерживать уже имеющиеся решения на glusterfs3, и будут предоставлены
> актуальные библиотеки, пакеты которых таки лучше привести в 
> соответствие
> Shared library policy.
Не очень понял, с какими проблемами мы столкнулись.

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

Re: [devel] libglusterfs6: shlib policy issue

[Vladimir D. Seleznev]

On Sun, Jun 16, 2019 at 01:45:19AM +0300, Vitaly Lipatov wrote:
> Vladimir D. Seleznev писал 15.6.19 22:43:
> > On Sat, Jun 15, 2019 at 01:56:26PM +0300, Vitaly Lipatov wrote:
> >> On Sat, 15 Jun 2019, Vladimir D. Seleznev wrote:
> >> 
> >> > Сонеймы, предоставляемые libglusterfs3, не поменялись. Зачем тогда надо
> >> > было переименовывать [1] пакет?
> >> 
> >> Пакет никто не переименовывал.  Просто новая мажорная версия собрана в
> >> свой набор пакетов, чтобы не произошло автоматического обновления,
> >> которое недопустимо для системы хранения данных.
> >> 
> >> Alexey Shabalin писал 15.6.19 2:38:
> >> 
> >> > ...
> >> > Пока andy@ готовил пакет glusterfs, с provides и obsoletes, в Сизифе
> >> > появился glustetfs6. Поэтому мы решили не выкладывать его, а немного
> >> > доделать. А вообще бы хорошо убрать эти 3 и 6 из имени.
> >> 
> >> Не очень понятно, зачем нужно было при живом мантейнере glusterfs
> >> готовить какой-то альтернативный пакет, и никак не информировать. Если
> >> кто-то может заняться гластером, я с радостью перестану тянуть (и
> >> тестировать и эксплуатировать) эту достаточно тяжёлую ношу.
> >> 
> >> Про 3 и 6 в имени уже написал выше -- обновления не предусматривается.
> > 
> > Т.е., тут такой же случай, как и с PostgreSQL? Неправильно, что один и
> > тот же сонейм в репозитории предоставляют разные пакеты. Т.к. 
> > glusterfs3
> Почему неправильно?

А как это может быть правильно? Если библиотеки реализуют один
интерфейс, то зачем тогда их несколько? А если разный, то почему у них
одинаковый сонейм?

> > и glusterfs6 предоставляют в своих библиотеках одинаковый ABI + новый
> > ABI в glusterfs6, то надо, чтобы в репозитории были представлены
> Нет информации, что они там предоставляют.

На самом деле информация есть, и ldv@ даже показал, что они
предоставляют таки разный ABI.

> И я бы точно не стал смешивать клиентов разных версий.

А что их клиентам нужно? И к какой версии glusterfs должны обращаться их
клиенты?

$ rpm -qR qemu-block-gluster
libgfapi.so.0()(64bit) >= set:lgPQ2yjkgGI8PCWHeZlLK4CdlglL3nSLWc97a2b6cdQYBC2SN5
libgfapi.so.0(GFAPI_3.4.0)(64bit)
libgfapi.so.0(GFAPI_3.5.0)(64bit)
qemu-common = 4.0.0-alt1:sisyphus+231199.1000.7.1
rpmlib(PayloadIsLzma)

Я не знаком с glusterfs, но на их сайте описаны процессы миграции на
новые версии.

> > разделяемые библиотеки от glusterfs6, а в glusterfs3 не собирать
> > разделяемых библиотек. Тогда будут и два пакета, что позволит и
> > поддерживать уже имеющиеся решения на glusterfs3, и будут предоставлены
> > актуальные библиотеки, пакеты которых таки лучше привести в 
> > соответствие
> > Shared library policy.
> Не очень понял, с какими проблемами мы столкнулись.

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

Re: [devel] libglusterfs6: shlib policy issue

[Alexey Shabalin]

вс, 16 июн. 2019 г. в 22:25, Vladimir D. Seleznev <vseleznv@altlinux.org>:
>
> On Sun, Jun 16, 2019 at 01:45:19AM +0300, Vitaly Lipatov wrote:
> > Vladimir D. Seleznev писал 15.6.19 22:43:
> > > On Sat, Jun 15, 2019 at 01:56:26PM +0300, Vitaly Lipatov wrote:
> > >> On Sat, 15 Jun 2019, Vladimir D. Seleznev wrote:
> > >>
> > >> > Сонеймы, предоставляемые libglusterfs3, не поменялись. Зачем тогда надо
> > >> > было переименовывать [1] пакет?
> > >>
> > >> Пакет никто не переименовывал.  Просто новая мажорная версия собрана в
> > >> свой набор пакетов, чтобы не произошло автоматического обновления,
> > >> которое недопустимо для системы хранения данных.
> > >>
> > >> Alexey Shabalin писал 15.6.19 2:38:
> > >>
> > >> > ...
> > >> > Пока andy@ готовил пакет glusterfs, с provides и obsoletes, в Сизифе
> > >> > появился glustetfs6. Поэтому мы решили не выкладывать его, а немного
> > >> > доделать. А вообще бы хорошо убрать эти 3 и 6 из имени.
> > >>
> > >> Не очень понятно, зачем нужно было при живом мантейнере glusterfs
> > >> готовить какой-то альтернативный пакет, и никак не информировать. Если
> > >> кто-то может заняться гластером, я с радостью перестану тянуть (и
> > >> тестировать и эксплуатировать) эту достаточно тяжёлую ношу.
> > >>
> > >> Про 3 и 6 в имени уже написал выше -- обновления не предусматривается.
> > >
> > > Т.е., тут такой же случай, как и с PostgreSQL? Неправильно, что один и
> > > тот же сонейм в репозитории предоставляют разные пакеты. Т.к.
> > > glusterfs3
> > Почему неправильно?
>
> А как это может быть правильно? Если библиотеки реализуют один
> интерфейс, то зачем тогда их несколько? А если разный, то почему у них
> одинаковый сонейм?
>
> > > и glusterfs6 предоставляют в своих библиотеках одинаковый ABI + новый
> > > ABI в glusterfs6, то надо, чтобы в репозитории были представлены
> > Нет информации, что они там предоставляют.
>
> На самом деле информация есть, и ldv@ даже показал, что они
> предоставляют таки разный ABI.
>
> > И я бы точно не стал смешивать клиентов разных версий.
>
> А что их клиентам нужно? И к какой версии glusterfs должны обращаться их
> клиенты?
>
> $ rpm -qR qemu-block-gluster
> libgfapi.so.0()(64bit) >= set:lgPQ2yjkgGI8PCWHeZlLK4CdlglL3nSLWc97a2b6cdQYBC2SN5
> libgfapi.so.0(GFAPI_3.4.0)(64bit)
> libgfapi.so.0(GFAPI_3.5.0)(64bit)
> qemu-common = 4.0.0-alt1:sisyphus+231199.1000.7.1
> rpmlib(PayloadIsLzma)

У тебя устаревшая информация. qemu в sisyphus собрался автоматически
уже с libglusterfs6-api.

> Я не знаком с glusterfs, но на их сайте описаны процессы миграции на
> новые версии.
>
> > > разделяемые библиотеки от glusterfs6, а в glusterfs3 не собирать
> > > разделяемых библиотек. Тогда будут и два пакета, что позволит и
> > > поддерживать уже имеющиеся решения на glusterfs3, и будут предоставлены
> > > актуальные библиотеки, пакеты которых таки лучше привести в
> > > соответствие
> > > Shared library policy.
> > Не очень понял, с какими проблемами мы столкнулись.

Что решили? я хочу видеть glusterfs версии v6 в бранче p9. Можно
перекладывать в таком виде, какой он в сизифе?

-- 
Alexey Shabalin

Re: [devel] libglusterfs6: shlib policy issue

[Alexey Shabalin]

> Не очень понял, с какими проблемами мы столкнулись.

Мне, например, не нравится, что никто не провайдит имена без циферок.
Я хочу не задумываясь установить glusterfs и получить последнюю
версию.

-- 
Alexey Shabalin

Re: [devel] libglusterfs6: shlib policy issue

[Vitaly Lipatov]

Alexey Shabalin писал 17.6.19 22:58:
>> Не очень понял, с какими проблемами мы столкнулись.
> 
> Мне, например, не нравится, что никто не провайдит имена без циферок.
> Я хочу не задумываясь установить glusterfs и получить последнюю
> версию.
Может быть, начнём с добавления Provides: glusterfs ?


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

Re: [devel] libglusterfs6: shlib policy issue

[Denis Medvedev]

On воскресенье, 16 июня 2019 г. 01:42:49 MSK Vitaly Lipatov wrote:
> Alexey Shabalin писал 16.6.19 0:39:
> > ...
> > Не надо поддерживать glusterfs3.
> > End of live для gluster-4.0 был 20 июня 2018. А про третью версию и
> > говорить не стоит. Я поэтому и предлагаю убрать цифры из имени пакета.
> > И удалить glusterfs3 из репо.
> 
> Я уже написал, почему нельзя убирать цифры из имени пакета.
> И предлагаю оставить все эти вопросы на усмотрение мантейнера.
> Например, мне бы не хотелось, чтобы glusterfs3 вдруг перестал
> поддерживаться или был удалён, потому что эта версия ещё в эксплуатации.
Кстати, цифры в имени пакета усложняют автоматизированный поиск уязвимостей в 
пакете, так как связь названия пакета и стандартного его имени  в апстриме 
теряется.

Re: [devel] libglusterfs6: shlib policy issue

[Vladimir D. Seleznev]

On Sun, Jun 16, 2019 at 09:50:41AM +0300, Denis Medvedev wrote:
> On воскресенье, 16 июня 2019 г. 01:42:49 MSK Vitaly Lipatov wrote:
> > Alexey Shabalin писал 16.6.19 0:39:
> > > ...
> > > Не надо поддерживать glusterfs3.
> > > End of live для gluster-4.0 был 20 июня 2018. А про третью версию и
> > > говорить не стоит. Я поэтому и предлагаю убрать цифры из имени пакета.
> > > И удалить glusterfs3 из репо.
> > 
> > Я уже написал, почему нельзя убирать цифры из имени пакета.
> > И предлагаю оставить все эти вопросы на усмотрение мантейнера.
> > Например, мне бы не хотелось, чтобы glusterfs3 вдруг перестал
> > поддерживаться или был удалён, потому что эта версия ещё в эксплуатации.
> Кстати, цифры в имени пакета усложняют автоматизированный поиск уязвимостей в 
> пакете, так как связь названия пакета и стандартного его имени  в апстриме 
> теряется.

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

Автоматизированный поиск лучше вести по полю Url в пакете.

$ rpm -q --qf '%{url}\n' bash4
https://www.gnu.org/software/bash/

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