[devel] libwine.so.1

[devel] libwine.so.1

[Vitaly Lipatov]

Итак, у нас в репозитории есть несколько пакетов, предоставляющих
libwine.so.1

Конечно, можно начать их прятать из provides/requires, но может быть 
стоит сделать для них исключение из проверки или предложить какое-то 
оригинальное решение?

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

     NEW duplicate provides detected:
  Provide:               Providers:
  libwine.so.1           libwine libwine-vanilla
  libwine.so.1()(64bit)  libwine libwine-vanilla
     old duplicate provides resolved:
  Provide:               Providers:
  libwine.so.1           libwine libwine-vanilla
  libwine.so.1()(64bit)  libwine libwine-vanilla

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

Re: [devel] libwine.so.1

[Vitaly Lipatov]

Vitaly Lipatov писал 16.11.20 16:36:
> Итак, у нас в репозитории есть несколько пакетов, предоставляющих
> libwine.so.1
> 
> Конечно, можно начать их прятать из provides/requires, но может быть
> стоит сделать для них исключение из проверки или предложить какое-то
> оригинальное решение?
> 
> libwine.so.1 это не обычная библиотека, а некий символ среды
> исполнения, и, на мой взгляд, борьба с дубликатами, сделанными по
> ошибке, не должна её задевать.
> 
>     NEW duplicate provides detected:
>  Provide:               Providers:
>  libwine.so.1           libwine libwine-vanilla
>  libwine.so.1()(64bit)  libwine libwine-vanilla
>     old duplicate provides resolved:
>  Provide:               Providers:
>  libwine.so.1           libwine libwine-vanilla
>  libwine.so.1()(64bit)  libwine libwine-vanilla


Вот существует пакет mpi-selector, где Cisco придумала выставлять в 
profile.d
LD_LIBRARY_PATH=/usr/lib64/openmpi/lib

Или пакет libnsl2, где просто добавляется
$ cat /etc/ld.so.conf.d/libnsl2-x86_64.conf
/usr/lib64/nsl

Есть разные средства ездить на кривой козе.

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

Re: [devel] libwine.so.1

[Dmitry V. Levin]

On Mon, Nov 16, 2020 at 08:09:38PM +0300, Vitaly Lipatov wrote:
> Vitaly Lipatov писал 16.11.20 16:36:
> > Итак, у нас в репозитории есть несколько пакетов, предоставляющих
> > libwine.so.1
> > 
> > Конечно, можно начать их прятать из provides/requires, но может быть
> > стоит сделать для них исключение из проверки или предложить какое-то
> > оригинальное решение?
> > 
> > libwine.so.1 это не обычная библиотека, а некий символ среды
> > исполнения, и, на мой взгляд, борьба с дубликатами, сделанными по
> > ошибке, не должна её задевать.
> > 
> >     NEW duplicate provides detected:
> >  Provide:               Providers:
> >  libwine.so.1           libwine libwine-vanilla
> >  libwine.so.1()(64bit)  libwine libwine-vanilla
> >     old duplicate provides resolved:
> >  Provide:               Providers:
> >  libwine.so.1           libwine libwine-vanilla
> >  libwine.so.1()(64bit)  libwine libwine-vanilla
> 
> Вот существует пакет mpi-selector, где Cisco придумала выставлять в 
> profile.d
> LD_LIBRARY_PATH=/usr/lib64/openmpi/lib

Что с Cisco взять-то.

> Или пакет libnsl2, где просто добавляется
> $ cat /etc/ld.so.conf.d/libnsl2-x86_64.conf
> /usr/lib64/nsl

Это ровным счётом ничего не меняет:

$ rpmquery --provides -p /ALT/Sisyphus/files/x86_64/RPMS/libnsl2-1.1.0-alt1_1.x86_64.rpm 
libnsl.so.2()(64bit) = set:kdrTLOdVMsUXFP6xBGTARtuq6Zx4Gv1TaRjROc13U2Y4vgFt0g6R7dR9mY9vlxDhiUi7Z86ZbIaSXaP6Kl7FIwRBLnXkZ5EkeReqZmM4gDZ8oJaf4TGqH3dBgAIJpwa4nnrdCpk3CqGzVUBwPCTYMeqpqUSiLAl81CQ8iChLLDupAjSjhUDRJukBu3JyNpwVKTXmuJm5ZkBvYKhbcRqeIcEbMcYrh8FasZx
libnsl.so.2(LIBNSL_1.0)(64bit)  
libnsl.so.2(LIBNSL_1.0.1)(64bit)  
libnsl.so.2(LIBNSL_1.0.2)(64bit)  
libnsl.so.2(LIBNSL_PRIVATE)(64bit)  
libnsl2 = 1.1.0-alt1_1
$ apt-cache showpkg 'libnsl.so.2()(64bit)'
Package: libnsl.so.2()(64bit)
Versions: 

Reverse Depends: 
  slapi-nis,libnsl.so.2()(64bit) set:kgBCvAfltSQ1TaZatwhM8N1
  python3-modules-nis,libnsl.so.2()(64bit) set:khVs0AedrsaWHx64
  python-modules-nis,libnsl.so.2()(64bit) set:khVs0AedrsaWHx64
Dependencies: 
Provides: 
Reverse Provides: 
libnsl2 1.1.0-alt1_1@1511548748


-- 
ldv

Re: [devel] libwine.so.1

[Dmitry V. Levin]

On Mon, Nov 16, 2020 at 04:36:07PM +0300, Vitaly Lipatov wrote:
> Итак, у нас в репозитории есть несколько пакетов, предоставляющих
> libwine.so.1
> 
> Конечно, можно начать их прятать из provides/requires, но может быть 
> стоит сделать для них исключение из проверки или предложить какое-то 
> оригинальное решение?
> 
> libwine.so.1 это не обычная библиотека, а некий символ среды исполнения, 
> и, на мой взгляд, борьба с дубликатами, сделанными по ошибке, не должна 
> её задевать.
> 
>      NEW duplicate provides detected:
>   Provide:               Providers:
>   libwine.so.1           libwine libwine-vanilla
>   libwine.so.1()(64bit)  libwine libwine-vanilla
>      old duplicate provides resolved:
>   Provide:               Providers:
>   libwine.so.1           libwine libwine-vanilla
>   libwine.so.1()(64bit)  libwine libwine-vanilla

Я пока не готов делать исключения просто по именам.  Раздумываю, как бы
точно проверить, что библиотеки действительно идентичные по ABI.  Может
быть, abipkgdiff как-нибудь приспособить.


-- 
ldv

Re: [devel] libwine.so.1

[Vitaly Lipatov]

Dmitry V. Levin писал 16.11.20 20:15:
> On Mon, Nov 16, 2020 at 04:36:07PM +0300, Vitaly Lipatov wrote:
>> Итак, у нас в репозитории есть несколько пакетов, предоставляющих
>> libwine.so.1
>> 
>> Конечно, можно начать их прятать из provides/requires, но может быть
>> стоит сделать для них исключение из проверки или предложить какое-то
>> оригинальное решение?
>> 
>> libwine.so.1 это не обычная библиотека, а некий символ среды 
>> исполнения,
>> и, на мой взгляд, борьба с дубликатами, сделанными по ошибке, не 
>> должна
>> её задевать.
>> 
>>      NEW duplicate provides detected:
>>   Provide:               Providers:
>>   libwine.so.1           libwine libwine-vanilla
>>   libwine.so.1()(64bit)  libwine libwine-vanilla
>>      old duplicate provides resolved:
>>   Provide:               Providers:
>>   libwine.so.1           libwine libwine-vanilla
>>   libwine.so.1()(64bit)  libwine libwine-vanilla
> 
> Я пока не готов делать исключения просто по именам.  Раздумываю, как бы
> точно проверить, что библиотеки действительно идентичные по ABI.  Может
> быть, abipkgdiff как-нибудь приспособить.
Я не хотел бы интересоваться или обеспечивать идентичность ABI для этой 
библиотеки.

Тем более, что важна не идентичность ABI, а то, что все пользователи 
получают необходимый им ABI (к примеру, в библиотеке может быть и 
меняющийся набор непубличных вызовов).
Скажем так, пользователю важны не люмены в лампочке, а люксы на 
поверхности стола.

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

Re: [devel] libwine.so.1

[Dmitry V. Levin]

On Mon, Nov 16, 2020 at 08:24:56PM +0300, Vitaly Lipatov wrote:
> Dmitry V. Levin писал 16.11.20 20:15:
> > On Mon, Nov 16, 2020 at 04:36:07PM +0300, Vitaly Lipatov wrote:
> >> Итак, у нас в репозитории есть несколько пакетов, предоставляющих
> >> libwine.so.1
> >> 
> >> Конечно, можно начать их прятать из provides/requires, но может быть
> >> стоит сделать для них исключение из проверки или предложить какое-то
> >> оригинальное решение?
> >> 
> >> libwine.so.1 это не обычная библиотека, а некий символ среды 
> >> исполнения,
> >> и, на мой взгляд, борьба с дубликатами, сделанными по ошибке, не 
> >> должна
> >> её задевать.
> >> 
> >>      NEW duplicate provides detected:
> >>   Provide:               Providers:
> >>   libwine.so.1           libwine libwine-vanilla
> >>   libwine.so.1()(64bit)  libwine libwine-vanilla
> >>      old duplicate provides resolved:
> >>   Provide:               Providers:
> >>   libwine.so.1           libwine libwine-vanilla
> >>   libwine.so.1()(64bit)  libwine libwine-vanilla
> > 
> > Я пока не готов делать исключения просто по именам.  Раздумываю, как бы
> > точно проверить, что библиотеки действительно идентичные по ABI.  Может
> > быть, abipkgdiff как-нибудь приспособить.
> Я не хотел бы интересоваться или обеспечивать идентичность ABI для этой 
> библиотеки.
> 
> Тем более, что важна не идентичность ABI, а то, что все пользователи 
> получают необходимый им ABI (к примеру, в библиотеке может быть и 
> меняющийся набор непубличных вызовов).

Что такое набор непубличных вызовов?
ABI библиотеки - это интерфейс, которым могут пользоваться её клиенты,
в нём нет непубличной части.


-- 
ldv

Re: [devel] libwine.so.1

[Vitaly Lipatov]

Dmitry V. Levin писал 16.11.20 20:32:
...
> Что такое набор непубличных вызовов?
> ABI библиотеки - это интерфейс, которым могут пользоваться её клиенты,
> в нём нет непубличной части.
Технически частей нет, но формально есть набор т.н. документированных 
API. Например, определённых в заголовочном файле.

Конечно, я пытался перевести стрелки от «могут пользоваться» в сторону 
«пользуются в действительности». Например, можно рассуждать о том, что 
есть набор используемых ABI (для замкнутого репозитория) и не 
обязательно он полностью покрывает всё, что предоставляет библиотека.

Но в случае wine будет проще соответствовать требованию одинаковости 
ABI, отказаться от упаковки разных версий, например.


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

Re: [devel] libwine.so.1

[Dmitry V. Levin]

On Mon, Nov 16, 2020 at 09:17:55PM +0300, Vitaly Lipatov wrote:
> Dmitry V. Levin писал 16.11.20 20:32:
> ...
> > Что такое набор непубличных вызовов?
> > ABI библиотеки - это интерфейс, которым могут пользоваться её клиенты,
> > в нём нет непубличной части.
> Технически частей нет, но формально есть набор т.н. документированных 
> API. Например, определённых в заголовочном файле.
> 
> Конечно, я пытался перевести стрелки от «могут пользоваться» в сторону 
> «пользуются в действительности». Например, можно рассуждать о том, что 
> есть набор используемых ABI (для замкнутого репозитория) и не 
> обязательно он полностью покрывает всё, что предоставляет библиотека.
> 
> Но в случае wine будет проще соответствовать требованию одинаковости 
> ABI, отказаться от упаковки разных версий, например.

Ну вот на данный момент abipkgdiff ведёт себя так, как будто
libwine.so.1.0 у них совместимый.  Уж не знаю, то ли abipkgdiff чудит,
то ли действительно совместимый.


-- 
ldv

Re: [devel] libwine.so.1

[Vitaly Lipatov]

Dmitry V. Levin писал 16.11.20 20:12:
...
> Это ровным счётом ничего не меняет:
> 
> $ rpmquery --provides -p
> /ALT/Sisyphus/files/x86_64/RPMS/libnsl2-1.1.0-alt1_1.x86_64.rpm
> libnsl.so.2()(64bit) =
> set:kdrTLOdVMsUXFP6xBGTARtuq6Zx4Gv1TaRjROc13U2Y4vgFt0g6R7dR9mY9vlxDhiUi7Z86ZbIaSXaP6Kl7FIwRBLnXkZ5EkeReqZmM4gDZ8oJaf4TGqH3dBgAIJpwa4nnrdCpk3CqGzVUBwPCTYMeqpqUSiLAl81CQ8iChLLDupAjSjhUDRJukBu3JyNpwVKTXmuJm5ZkBvYKhbcRqeIcEbMcYrh8FasZx
> libnsl.so.2(LIBNSL_1.0)(64bit)
> libnsl.so.2(LIBNSL_1.0.1)(64bit)
> libnsl.so.2(LIBNSL_1.0.2)(64bit)
> libnsl.so.2(LIBNSL_PRIVATE)(64bit)
...
Я уже как-то помучался, пытаясь понять, что же в системе влияет на то, 
что зависимости  с длинным путём теряют путь, как будто библиотека лежит 
в _libdir.

Получается, этот путь объезда не работает, а подобная упаковка библиотек 
не имеет смысла, проще сразу положить в _libdir?

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

Re: [devel] libwine.so.1

[Dmitry V. Levin]

On Mon, Nov 16, 2020 at 10:14:26PM +0300, Vitaly Lipatov wrote:
> Dmitry V. Levin писал 16.11.20 20:12:
> ...
> > Это ровным счётом ничего не меняет:
> > 
> > $ rpmquery --provides -p
> > /ALT/Sisyphus/files/x86_64/RPMS/libnsl2-1.1.0-alt1_1.x86_64.rpm
> > libnsl.so.2()(64bit) =
> > set:kdrTLOdVMsUXFP6xBGTARtuq6Zx4Gv1TaRjROc13U2Y4vgFt0g6R7dR9mY9vlxDhiUi7Z86ZbIaSXaP6Kl7FIwRBLnXkZ5EkeReqZmM4gDZ8oJaf4TGqH3dBgAIJpwa4nnrdCpk3CqGzVUBwPCTYMeqpqUSiLAl81CQ8iChLLDupAjSjhUDRJukBu3JyNpwVKTXmuJm5ZkBvYKhbcRqeIcEbMcYrh8FasZx
> > libnsl.so.2(LIBNSL_1.0)(64bit)
> > libnsl.so.2(LIBNSL_1.0.1)(64bit)
> > libnsl.so.2(LIBNSL_1.0.2)(64bit)
> > libnsl.so.2(LIBNSL_PRIVATE)(64bit)
> ...
> Я уже как-то помучался, пытаясь понять, что же в системе влияет на то, 
> что зависимости  с длинным путём теряют путь, как будто библиотека лежит 
> в _libdir.
> 
> Получается, этот путь объезда не работает, а подобная упаковка библиотек 
> не имеет смысла, проще сразу положить в _libdir?

Конечно.  А что вы таким образом хотели объехать?


-- 
ldv

Re: [devel] libwine.so.1

[Konstantin Lepikhov]

Hi Vitaly!

On 11/16/2020, at 09:17:55 PM you wrote:

> Dmitry V. Levin писал 16.11.20 20:32:
> ...
> > Что такое набор непубличных вызовов?
> > ABI библиотеки - это интерфейс, которым могут пользоваться её клиенты,
> > в нём нет непубличной части.
> Технически частей нет, но формально есть набор т.н. документированных 
> API. Например, определённых в заголовочном файле.
> 
> Конечно, я пытался перевести стрелки от «могут пользоваться» в сторону 
> «пользуются в действительности». Например, можно рассуждать о том, что 
> есть набор используемых ABI (для замкнутого репозитория) и не 
> обязательно он полностью покрывает всё, что предоставляет библиотека.
> 
> Но в случае wine будет проще соответствовать требованию одинаковости 
> ABI, отказаться от упаковки разных версий, например.
В staging ABI точно другой, но там и библиотека называется
libwine-staging (по-крайней мере, у себя в сборке я так сделал). Что
мешает назвать libwine libwine-bla-bla?

-- 
WBR et al.

Re: [devel] libwine.so.1

[Mikhail Novosyolov]

17.11.2020 12:32, Konstantin Lepikhov пишет:
> Hi Vitaly!
>
> On 11/16/2020, at 09:17:55 PM you wrote:
>
>> Dmitry V. Levin писал 16.11.20 20:32:
>> ...
>>> Что такое набор непубличных вызовов?
>>> ABI библиотеки - это интерфейс, которым могут пользоваться её клиенты,
>>> в нём нет непубличной части.
>> Технически частей нет, но формально есть набор т.н. документированных 
>> API. Например, определённых в заголовочном файле.
>>
>> Конечно, я пытался перевести стрелки от «могут пользоваться» в сторону 
>> «пользуются в действительности». Например, можно рассуждать о том, что 
>> есть набор используемых ABI (для замкнутого репозитория) и не 
>> обязательно он полностью покрывает всё, что предоставляет библиотека.
>>
>> Но в случае wine будет проще соответствовать требованию одинаковости 
>> ABI, отказаться от упаковки разных версий, например.
> В staging ABI точно другой, но там и библиотека называется
> libwine-staging (по-крайней мере, у себя в сборке я так сделал). Что
> мешает назвать libwine libwine-bla-bla?
>
А модули wine типа транслятора криптопро не перестанут работать с обоими вариантами wine?

Re: [devel] libwine.so.1

[Konstantin Lepikhov]

Hi Mikhail!

On 11/17/2020, at 03:18:58 PM you wrote:

> 17.11.2020 12:32, Konstantin Lepikhov пишет:
> > Hi Vitaly!
> >
> > On 11/16/2020, at 09:17:55 PM you wrote:
> >
> >> Dmitry V. Levin писал 16.11.20 20:32:
> >> ...
> >>> Что такое набор непубличных вызовов?
> >>> ABI библиотеки - это интерфейс, которым могут пользоваться её клиенты,
> >>> в нём нет непубличной части.
> >> Технически частей нет, но формально есть набор т.н. документированных 
> >> API. Например, определённых в заголовочном файле.
> >>
> >> Конечно, я пытался перевести стрелки от «могут пользоваться» в сторону 
> >> «пользуются в действительности». Например, можно рассуждать о том, что 
> >> есть набор используемых ABI (для замкнутого репозитория) и не 
> >> обязательно он полностью покрывает всё, что предоставляет библиотека.
> >>
> >> Но в случае wine будет проще соответствовать требованию одинаковости 
> >> ABI, отказаться от упаковки разных версий, например.
> > В staging ABI точно другой, но там и библиотека называется
> > libwine-staging (по-крайней мере, у себя в сборке я так сделал). Что
> > мешает назвать libwine libwine-bla-bla?
> >
> А модули wine типа транслятора криптопро не перестанут работать с обоими вариантами wine?
Кто написал эти модули? Наверное, там можно указать какую библиотеку
использовать.

-- 
WBR et al.