[devel] I: duplicate pkgconfig() provides

[devel] I: duplicate pkgconfig() provides

[Dmitry V. Levin]

Hi,

У нас в репозитории обнаружилось 29 дубликатов pkgconfig provides.

Несмотря на то, что все эти provides версионированы, такое дублирование
вредно: provides с дубликатами невозможно нормально использовать в
сборочных зависимостях, поскольку приходится добавлять версии и/или
имена devel-пакетов вручную.

Даже в версионированных pkgconfig requires, сгенерированных из .pc-файлов
автоматически, указанного диапазона версий может быть недостаточно для
выбора правильного варианта pkgconfig provides из нескольких кандидатов.

$ pkglist-query '[%{PROVIDENAME} %{NAME} %{PROVIDEFLAGS:depflags}%{PROVIDEVERSION}\n]' Sisyphus/{x86_64,noarch}/base.bloat/pkglist.classic |sed -rn -e 's/ \+$//' -e 's/^(pkgconfig\([^ ]+) ([^ ]+) ([^ ]*)$/=\3 \2 \1/p' |sort -k3 |uniq -D -f2 |sed -rn -e 's/^([^ ]+) ([^ ]+) ([^ ]+)$/\2 \3 \1/p' |sort -k2 |column -t -N 'Package:,Provide Name:,Provide Version:'
Package:                          Provide Name:               Provide Version:
ilmbase24-devel                   pkgconfig(IlmBase)          ==2.3.0
ilmbase-devel                     pkgconfig(IlmBase)          ==2.5.3
openexr24-devel                   pkgconfig(OpenEXR)          ==2.3.0
openexr-devel                     pkgconfig(OpenEXR)          ==2.5.3
python-module-pycxx-devel         pkgconfig(PyCXX)            ==7.1.4
python3-module-pycxx-devel        pkgconfig(PyCXX)            ==7.1.4
libbullet-devel                   pkgconfig(bullet)           ==2.82
libbullet3-devel                  pkgconfig(bullet)           ==2.88
python-module-caja-devel          pkgconfig(caja-python)      ==1.20.0
python3-module-caja-devel         pkgconfig(caja-python)      ==1.24.0
dataquay-devel                    pkgconfig(dataquay)         ==0.9
dataquay-minefeld-devel           pkgconfig(dataquay)         ==0.9
libglusterfs7-api-devel           pkgconfig(glusterfs-api)    ==7.7.8
libglusterfs8-api-devel           pkgconfig(glusterfs-api)    ==7.8.2
libilbc1-devel                    pkgconfig(ilbc)             ==0.0.2
ilbc-devel                        pkgconfig(ilbc)             ==1.1.1
libdivecomputer-devel             pkgconfig(libdivecomputer)  ==0.6.0
libdivecomputer-subsurface-devel  pkgconfig(libdivecomputer)  ==4.9.6
libglusterfs7-devel               pkgconfig(libgfchangelog)   ==0.0.1
libglusterfs8-devel               pkgconfig(libgfchangelog)   ==0.0.1
libeudev-devel                    pkgconfig(libudev)          ==243
libudev-devel                     pkgconfig(libudev)          ==246
liblua5.1-compat-devel            pkgconfig(lua)              ==5.1.5
liblua5.3-devel                   pkgconfig(lua)              ==5.3.0
libminizip-devel                  pkgconfig(minizip)          ==1.2.11
libminizip2-devel                 pkgconfig(minizip)          ==2.10.2
libnetcdf-mpi-devel               pkgconfig(netcdf)           ==4.4.1.1-alt2
libnetcdf-devel                   pkgconfig(netcdf)           ==4.4.1.1-alt3
openh264-devel                    pkgconfig(openh264)         ==2.1.0
libopenh264-devel                 pkgconfig(openh264)         ==2.1.1
libortp0.7-devel                  pkgconfig(ortp)             ==0.7.1
libortp-devel                     pkgconfig(ortp)             ==1.0.1
python3-module-pygobject-devel    pkgconfig(pygobject-2.0)    ==2.28.6
python-module-pygobject-devel     pkgconfig(pygobject-2.0)    ==2.28.7
python-module-pygobject3-devel    pkgconfig(pygobject-3.0)    ==3.36.1
python3-module-pygobject3-devel   pkgconfig(pygobject-3.0)    ==3.38.0
libpyside-qt4-devel               pkgconfig(pyside)           ==1.2.2
libpyside-qt4-py3-devel           pkgconfig(pyside)           ==1.2.2
python-module-PySide2-devel       pkgconfig(pyside2)          ==5.15.0
python3-module-PySide2-devel      pkgconfig(pyside2)          ==5.15.0
libqimageblitz-devel              pkgconfig(qimageblitz)      ==4.0.0
qimageblitz5-devel                pkgconfig(qimageblitz)      ==5.0.0
qoauth-devel                      pkgconfig(qoauth)           ==1.0.1
qoauth-qt5-devel                  pkgconfig(qoauth)           ==2.0.0
libshiboken-devel                 pkgconfig(shiboken)         ==1.2.2
libshiboken-py3-devel             pkgconfig(shiboken)         ==1.2.2
python-module-shiboken2-devel     pkgconfig(shiboken2)        ==5.15.0
python3-module-shiboken2-devel    pkgconfig(shiboken2)        ==5.15.0
libspandsp-devel                  pkgconfig(spandsp)          ==0.0.6
libspandsp3-devel                 pkgconfig(spandsp)          ==3.0.0
libticables-devel                 pkgconfig(ticables2)        ==1.3.4
libticables2-devel                pkgconfig(ticables2)        ==1.3.5
libvpx5-devel                     pkgconfig(vpx)              ==1.7.0
libvpx-devel                      pkgconfig(vpx)              ==1.9.0
libwxGTK3.1-sqlite3-devel         pkgconfig(wxsqlite3)        ==4.0.2
libwxGTK3.0-sqlite3-devel         pkgconfig(wxsqlite3)        ==4.5.1
libxerces-c28-devel               pkgconfig(xerces-c)         ==2.8.0
libxerces-c-devel                 pkgconfig(xerces-c)         ==3.2.3

Обратите внимание на часть этой таблицы:
Package:                        Provide Name:              Provide Version:
python-module-pycxx-devel       pkgconfig(PyCXX)           =7.1.4
python3-module-pycxx-devel      pkgconfig(PyCXX)           =7.1.4
dataquay-devel                  pkgconfig(dataquay)        =0.9
dataquay-minefeld-devel         pkgconfig(dataquay)        =0.9
libglusterfs7-devel             pkgconfig(libgfchangelog)  =0.0.1
libglusterfs8-devel             pkgconfig(libgfchangelog)  =0.0.1
libpyside-qt4-devel             pkgconfig(pyside)          =1.2.2
libpyside-qt4-py3-devel         pkgconfig(pyside)          =1.2.2
python-module-PySide2-devel     pkgconfig(pyside2)         =5.15.0
python3-module-PySide2-devel    pkgconfig(pyside2)         =5.15.0
libshiboken-devel               pkgconfig(shiboken)        =1.2.2
libshiboken-py3-devel           pkgconfig(shiboken)        =1.2.2
python-module-shiboken2-devel   pkgconfig(shiboken2)       =5.15.0
python3-module-shiboken2-devel  pkgconfig(shiboken2)       =5.15.0

Я не вижу другого выхода, кроме как запретить дублирование pkgconfig provides.


-- 
ldv

Re: [devel] I: duplicate pkgconfig() provides

[Yuri Sedunov]

В Сб, 14/11/2020 в 17:59 +0300, Dmitry V. Levin пишет:
> Hi,
...

> имена devel-пакетов вручную.
> 

> python3-module-pygobject-devel    pkgconfig(pygobject-2.0)   ==2.28.6
> python-module-pygobject-devel     pkgconfig(pygobject-2.0)   ==2.28.7
> python-module-pygobject3-devel    pkgconfig(pygobject-3.0)   ==3.36.1
> python3-module-pygobject3-devel   pkgconfig(pygobject-3.0)   ==3.38.0

Это всегда будут pygobject'ы второй и третьей версий, для python 2
python 3 каждый. Никаких проблем в указании конкретного *pygobject*-
devel пакета в качестве сборочной зависимости никто не испытывает.

И только лишь python-module-pygtk-devel имеет автоматическую
зависимость на pkgconfig(pygobject-2.0) кроме ручной на python-module-
pygobject-devel.

С этим надо смириться.

-- 
Yuri N. Sedunov

Re: [devel] I: duplicate pkgconfig() provides

[Dmitry V. Levin]

On Sat, Nov 14, 2020 at 06:51:55PM +0300, Yuri Sedunov wrote:
> В Сб, 14/11/2020 в 17:59 +0300, Dmitry V. Levin пишет:
> > Hi,
> ...
> 
> > имена devel-пакетов вручную.
> > 
> 
> > python3-module-pygobject-devel    pkgconfig(pygobject-2.0)   ==2.28.6
> > python-module-pygobject-devel     pkgconfig(pygobject-2.0)   ==2.28.7
> > python-module-pygobject3-devel    pkgconfig(pygobject-3.0)   ==3.36.1
> > python3-module-pygobject3-devel   pkgconfig(pygobject-3.0)   ==3.38.0
> 
> Это всегда будут pygobject'ы второй и третьей версий, для python 2
> python 3 каждый. Никаких проблем в указании конкретного *pygobject*-
> devel пакета в качестве сборочной зависимости никто не испытывает.
> 
> И только лишь python-module-pygtk-devel имеет автоматическую
> зависимость на pkgconfig(pygobject-2.0) кроме ручной на python-module-
> pygobject-devel.
> 
> С этим надо смириться.

Так, а есть ли тогда от этих pkgconfig(pygobject-2.0) и
pkgconfig(pygobject-3.0) хоть какая-нибудь польза?


-- 
ldv

Re: [devel] I: duplicate pkgconfig() provides

[Yuri Sedunov]

В Сб, 14/11/2020 в 19:29 +0300, Dmitry V. Levin пишет:
> On Sat, Nov 14, 2020 at 06:51:55PM +0300, Yuri Sedunov wrote:
> > В Сб, 14/11/2020 в 17:59 +0300, Dmitry V. Levin пишет:
> > > Hi,
> > ...
> > 
> > > имена devel-пакетов вручную.
> > > 
> > 
> > > python3-module-pygobject-devel    pkgconfig(pygobject-
> > > 2.0)   ==2.28.6
> > > python-module-pygobject-devel     pkgconfig(pygobject-
> > > 2.0)   ==2.28.7
> > > python-module-pygobject3-devel    pkgconfig(pygobject-
> > > 3.0)   ==3.36.1
> > > python3-module-pygobject3-devel   pkgconfig(pygobject-
> > > 3.0)   ==3.38.0
> > 
> > Это всегда будут pygobject'ы второй и третьей версий, для python 2
> > python 3 каждый. Никаких проблем в указании конкретного
> > *pygobject*-
> > devel пакета в качестве сборочной зависимости никто не испытывает.
> > 
> > И только лишь python-module-pygtk-devel имеет автоматическую
> > зависимость на pkgconfig(pygobject-2.0) кроме ручной на python-
> > module-
> > pygobject-devel.
> > 
> > С этим надо смириться.
> 
> Так, а есть ли тогда от этих pkgconfig(pygobject-2.0) и
> pkgconfig(pygobject-3.0) хоть какая-нибудь польза?
> 

Кроме PyGTK? -- да, бывают нужны. У тебя есть логи пересборки сизифа,
их можно пошерстить.

-- 
Yuri N. Sedunov

Re: [devel] I: duplicate pkgconfig() provides

[Dmitry V. Levin]

On Sat, Nov 14, 2020 at 08:02:46PM +0300, Yuri Sedunov wrote:
> В Сб, 14/11/2020 в 19:29 +0300, Dmitry V. Levin пишет:
> > On Sat, Nov 14, 2020 at 06:51:55PM +0300, Yuri Sedunov wrote:
> > > В Сб, 14/11/2020 в 17:59 +0300, Dmitry V. Levin пишет:
> > > > Hi,
> > > ...
> > > 
> > > > имена devel-пакетов вручную.
> > > > 
> > > 
> > > > python3-module-pygobject-devel    pkgconfig(pygobject-
> > > > 2.0)   ==2.28.6
> > > > python-module-pygobject-devel     pkgconfig(pygobject-
> > > > 2.0)   ==2.28.7
> > > > python-module-pygobject3-devel    pkgconfig(pygobject-
> > > > 3.0)   ==3.36.1
> > > > python3-module-pygobject3-devel   pkgconfig(pygobject-
> > > > 3.0)   ==3.38.0
> > > 
> > > Это всегда будут pygobject'ы второй и третьей версий, для python 2
> > > python 3 каждый. Никаких проблем в указании конкретного
> > > *pygobject*-
> > > devel пакета в качестве сборочной зависимости никто не испытывает.
> > > 
> > > И только лишь python-module-pygtk-devel имеет автоматическую
> > > зависимость на pkgconfig(pygobject-2.0) кроме ручной на python-
> > > module-
> > > pygobject-devel.
> > > 
> > > С этим надо смириться.
> > 
> > Так, а есть ли тогда от этих pkgconfig(pygobject-2.0) и
> > pkgconfig(pygobject-3.0) хоть какая-нибудь польза?
> 
> Кроме PyGTK? -- да, бывают нужны. У тебя есть логи пересборки сизифа,
> их можно пошерстить.

python*-module-pygobject*-devel, конечно, присутствуют в сборочной среде
74 пакетов, но по логам сборки не видно, нужны были эти Provides или нет.

Поиск по всем спекам даёт такой результат:

$ git --git-dir=/people/specbot/public/specs.git grep '^[^#]*pkgconfig(pygobject-[23]\.0)' @
@:a/avahi/avahi.spec:BuildRequires: python3-devel python3(dbus) pkgconfig(pygobject-3.0)
@:b/blueman/blueman.spec:BuildRequires: pkgconfig(pygobject-3.0)
@:m/mate-menu-editor/mozo.spec:BuildRequires: pkgconfig(libmate-menu) pkgconfig(pygobject-3.0)

Во всех трёх случаях без явного указания в спеках был каким-то образом
выбран python3-module-pygobject3-devel:

$ printf 'avahi\nblueman\nmate-menu-editor\n' |\
  join -o2.2 - beehive/stats/Sisyphus-x86_64/ufb-1 |\
  grep 'pygobject.*devel'
python3-module-pygobject3-devel
python3-module-pygobject3-devel
python3-module-pygobject3-devel


-- 
ldv

Re: [devel] I: duplicate pkgconfig() provides

[Yuri Sedunov]

В Сб, 14/11/2020 в 22:04 +0300, Dmitry V. Levin пишет:
> On Sat, Nov 14, 2020 at 08:02:46PM +0300, Yuri Sedunov wrote:
> > В Сб, 14/11/2020 в 19:29 +0300, Dmitry V. Levin пишет:
> > > On Sat, Nov 14, 2020 at 06:51:55PM +0300, Yuri Sedunov wrote:
> > > > В Сб, 14/11/2020 в 17:59 +0300, Dmitry V. Levin пишет:
> > > > > Hi,
> > > > ...
> > > > 
> > > > > имена devel-пакетов вручную.
> > > > > 
> > > > 
> > > > > python3-module-pygobject-devel    pkgconfig(pygobject-
> > > > > 2.0)   ==2.28.6
> > > > > python-module-pygobject-devel     pkgconfig(pygobject-
> > > > > 2.0)   ==2.28.7
> > > > > python-module-pygobject3-devel    pkgconfig(pygobject-
> > > > > 3.0)   ==3.36.1
> > > > > python3-module-pygobject3-devel   pkgconfig(pygobject-
> > > > > 3.0)   ==3.38.0
> > > > 
> > > > Это всегда будут pygobject'ы второй и третьей версий, для
> > > > python 2
> > > > python 3 каждый. Никаких проблем в указании конкретного
> > > > *pygobject*-
> > > > devel пакета в качестве сборочной зависимости никто не
> > > > испытывает.
> > > > 
> > > > И только лишь python-module-pygtk-devel имеет автоматическую
> > > > зависимость на pkgconfig(pygobject-2.0) кроме ручной на python-
> > > > module-
> > > > pygobject-devel.
> > > > 
> > > > С этим надо смириться.
> > > 
> > > Так, а есть ли тогда от этих pkgconfig(pygobject-2.0) и
> > > pkgconfig(pygobject-3.0) хоть какая-нибудь польза?
> > 
> > Кроме PyGTK? -- да, бывают нужны. У тебя есть логи пересборки
> > сизифа,
> > их можно пошерстить.
> 
> python*-module-pygobject*-devel, конечно, присутствуют в сборочной
> среде 74 пакетов, но по логам сборки не видно, нужны были эти
> Provides или нет.

Видимо, надо тщательнее шерстить. Например, в mypaint среди флагов
компиляции есть -I/usr/include/pygobject-3.0, что в логе сборки видно,
и неспроста, в setup.py егоном есть следующий фрагмент:

    initial_deps = ["%s >= 1.6" % LIBMYPAINT]
    remaining_deps = [
        "pygobject-3.0",
        "glib-2.0",
        "libpng",
        "lcms2",
        "gtk+-3.0",
        "mypaint-brushes-2.0",
    ]
    check_dependencies(initial_deps + remaining_deps)

> Поиск по всем спекам даёт такой результат:
> 
> $ git --git-dir=/people/specbot/public/specs.git grep
> '^[^#]*pkgconfig(pygobject-[23]\.0)' @
> @:a/avahi/avahi.spec:BuildRequires: python3-devel python3(dbus)
> pkgconfig(pygobject-3.0)
> @:b/blueman/blueman.spec:BuildRequires: pkgconfig(pygobject-3.0)
> @:m/mate-menu-editor/mozo.spec:BuildRequires: pkgconfig(libmate-menu)
> pkgconfig(pygobject-3.0)
> 
> Во всех трёх случаях без явного указания в спеках был каким-то
> образом выбран python3-module-pygobject3-devel:
> 
> $ printf 'avahi\nblueman\nmate-menu-editor\n' |\
>   join -o2.2 - beehive/stats/Sisyphus-x86_64/ufb-1 |\
>   grep 'pygobject.*devel'
> python3-module-pygobject3-devel
> python3-module-pygobject3-devel
> python3-module-pygobject3-devel
> 

Ну, это, наверное, потому, что всё остальное требуемое для сборки --
python3-based, apt иногда делает что-то разумное и логичное.


-- 
Yuri N. Sedunov

Re: [devel] I: duplicate pkgconfig() provides

[Dmitry V. Levin]

On Sat, Nov 14, 2020 at 11:22:41PM +0300, Yuri Sedunov wrote:
> В Сб, 14/11/2020 в 22:04 +0300, Dmitry V. Levin пишет:
> > On Sat, Nov 14, 2020 at 08:02:46PM +0300, Yuri Sedunov wrote:
> > > В Сб, 14/11/2020 в 19:29 +0300, Dmitry V. Levin пишет:
> > > > On Sat, Nov 14, 2020 at 06:51:55PM +0300, Yuri Sedunov wrote:
> > > > > В Сб, 14/11/2020 в 17:59 +0300, Dmitry V. Levin пишет:
> > > > > > Hi,
> > > > > ...
> > > > > 
> > > > > > имена devel-пакетов вручную.
> > > > > > 
> > > > > 
> > > > > > python3-module-pygobject-devel    pkgconfig(pygobject-
> > > > > > 2.0)   ==2.28.6
> > > > > > python-module-pygobject-devel     pkgconfig(pygobject-
> > > > > > 2.0)   ==2.28.7
> > > > > > python-module-pygobject3-devel    pkgconfig(pygobject-
> > > > > > 3.0)   ==3.36.1
> > > > > > python3-module-pygobject3-devel   pkgconfig(pygobject-
> > > > > > 3.0)   ==3.38.0
> > > > > 
> > > > > Это всегда будут pygobject'ы второй и третьей версий, для
> > > > > python 2
> > > > > python 3 каждый. Никаких проблем в указании конкретного
> > > > > *pygobject*-
> > > > > devel пакета в качестве сборочной зависимости никто не
> > > > > испытывает.
> > > > > 
> > > > > И только лишь python-module-pygtk-devel имеет автоматическую
> > > > > зависимость на pkgconfig(pygobject-2.0) кроме ручной на python-
> > > > > module-
> > > > > pygobject-devel.
> > > > > 
> > > > > С этим надо смириться.
> > > > 
> > > > Так, а есть ли тогда от этих pkgconfig(pygobject-2.0) и
> > > > pkgconfig(pygobject-3.0) хоть какая-нибудь польза?
> > > 
> > > Кроме PyGTK? -- да, бывают нужны. У тебя есть логи пересборки
> > > сизифа,
> > > их можно пошерстить.
> > 
> > python*-module-pygobject*-devel, конечно, присутствуют в сборочной
> > среде 74 пакетов, но по логам сборки не видно, нужны были эти
> > Provides или нет.
> 
> Видимо, надо тщательнее шерстить. Например, в mypaint среди флагов
> компиляции есть -I/usr/include/pygobject-3.0, что в логе сборки видно,
> и неспроста, в setup.py егоном есть следующий фрагмент:
> 
>     initial_deps = ["%s >= 1.6" % LIBMYPAINT]
>     remaining_deps = [
>         "pygobject-3.0",
>         "glib-2.0",
>         "libpng",
>         "lcms2",
>         "gtk+-3.0",
>         "mypaint-brushes-2.0",
>     ]
>     check_dependencies(initial_deps + remaining_deps)

Да, но setup.py не оперирует зависимостями пакетов, ему всё равно, есть
ли у pygobject-3.0.pc какой-нибудь Provides: pkgconfig(pygobject-3.0.pc)
или нет.

> > Поиск по всем спекам даёт такой результат:
> > 
> > $ git --git-dir=/people/specbot/public/specs.git grep
> > '^[^#]*pkgconfig(pygobject-[23]\.0)' @
> > @:a/avahi/avahi.spec:BuildRequires: python3-devel python3(dbus)
> > pkgconfig(pygobject-3.0) @:b/blueman/blueman.spec:BuildRequires:
> > pkgconfig(pygobject-3.0) @:m/mate-menu-editor/mozo.spec:BuildRequires:
> > pkgconfig(libmate-menu) pkgconfig(pygobject-3.0)
> > 
> > Во всех трёх случаях без явного указания в спеках был каким-то образом
> > выбран python3-module-pygobject3-devel:
> > 
> > $ printf 'avahi\nblueman\nmate-menu-editor\n' |\   join -o2.2 -
> > beehive/stats/Sisyphus-x86_64/ufb-1 |\   grep 'pygobject.*devel'
> > python3-module-pygobject3-devel python3-module-pygobject3-devel
> > python3-module-pygobject3-devel
> 
> Ну, это, наверное, потому, что всё остальное требуемое для сборки --
> python3-based, apt иногда делает что-то разумное и логичное.

Т.е. нам просто повезло, что по зависимости на pkgconfig(pygobject-3.0)
вытянулся python3-module-pygobject3-devel, а не
python-module-pygobject3-devel.


-- 
ldv

Re: [devel] I: duplicate pkgconfig() provides

[Yuri Sedunov]

В Вс, 15/11/2020 в 01:09 +0300, Dmitry V. Levin пишет:
> On Sat, Nov 14, 2020 at 11:22:41PM +0300, Yuri Sedunov wrote:
> > В Сб, 14/11/2020 в 22:04 +0300, Dmitry V. Levin пишет:
> > > On Sat, Nov 14, 2020 at 08:02:46PM +0300, Yuri Sedunov wrote:
> > > > В Сб, 14/11/2020 в 19:29 +0300, Dmitry V. Levin пишет:
> > > > > On Sat, Nov 14, 2020 at 06:51:55PM +0300, Yuri Sedunov wrote:
> > > > > > В Сб, 14/11/2020 в 17:59 +0300, Dmitry V. Levin пишет:
> > > > > > > Hi,
> > > > > > ...
> > > > > > 
> > > > > > > имена devel-пакетов вручную.
> > > > > > > 
> > > > > > 
> > > > > > > python3-module-pygobject-devel    pkgconfig(pygobject-
> > > > > > > 2.0)   ==2.28.6
> > > > > > > python-module-pygobject-devel     pkgconfig(pygobject-
> > > > > > > 2.0)   ==2.28.7
> > > > > > > python-module-pygobject3-devel    pkgconfig(pygobject-
> > > > > > > 3.0)   ==3.36.1
> > > > > > > python3-module-pygobject3-devel   pkgconfig(pygobject-
> > > > > > > 3.0)   ==3.38.0
> > > > > > 
> > > > > > Это всегда будут pygobject'ы второй и третьей версий, для
> > > > > > python 2 python 3 каждый. Никаких проблем в указании
> > > > > > конкретного *pygobject*-devel пакета в качестве сборочной
> > > > > > зависимости никто не испытывает.
> > > > > > 
> > > > > > И только лишь python-module-pygtk-devel имеет
> > > > > > автоматическую зависимость на pkgconfig(pygobject-2.0)
> > > > > > кроме ручной на python-module-pygobject-devel.
> > > > > > 
> > > > > > С этим надо смириться.
> > > > > 
> > > > > Так, а есть ли тогда от этих pkgconfig(pygobject-2.0) и
> > > > > pkgconfig(pygobject-3.0) хоть какая-нибудь польза?
> > > > 
> > > > Кроме PyGTK? -- да, бывают нужны. У тебя есть логи пересборки
> > > > сизифа, их можно пошерстить.
> > > 
> > > python*-module-pygobject*-devel, конечно, присутствуют в
> > > сборочной среде 74 пакетов, но по логам сборки не видно, нужны
> > > были эти Provides или нет.
> > 
> > Видимо, надо тщательнее шерстить. Например, в mypaint среди флагов
> > компиляции есть -I/usr/include/pygobject-3.0, что в логе сборки
> > видно, и неспроста, в setup.py егоном есть следующий фрагмент:
> > 
> >     initial_deps = ["%s >= 1.6" % LIBMYPAINT]
> >     remaining_deps = [
> >         "pygobject-3.0",
> >         "glib-2.0",
> >         "libpng",
> >         "lcms2",
> >         "gtk+-3.0",
> >         "mypaint-brushes-2.0",
> >     ]
> >     check_dependencies(initial_deps + remaining_deps)
> 
> Да, но setup.py не оперирует зависимостями пакетов, ему всё равно,
> есть ли у pygobject-3.0.pc какой-нибудь Provides:
> pkgconfig(pygobject-3.0.pc) или нет.

Неправильно понял, Подумалось, что ты хочешь вовсе лишить какие-то
pygobject'ы pc-файлов.

Только у python-module-pygtk-devel есть зависимость на
pkgconfig(pygobject-2.0).

Сделал тестовое задание, в котором вырезал у уходящих python-module-
pygobject*-devel соответствующие Provides, а у python-module-pygtk-
devel зависимость на pkgconfig(pygobject-2.0).

Устроит?

> > > Поиск по всем спекам даёт такой результат:
> > > 
> > > $ git --git-dir=/people/specbot/public/specs.git grep
> > > '^[^#]*pkgconfig(pygobject-[23]\.0)' @
> > > @:a/avahi/avahi.spec:BuildRequires: python3-devel python3(dbus)
> > > pkgconfig(pygobject-3.0) @:b/blueman/blueman.spec:BuildRequires:
> > > pkgconfig(pygobject-3.0) @:m/mate-menu-
> > > editor/mozo.spec:BuildRequires:
> > > pkgconfig(libmate-menu) pkgconfig(pygobject-3.0)
> > > 
> > > Во всех трёх случаях без явного указания в спеках был каким-то
> > > образом выбран python3-module-pygobject3-devel:
> > > 
> > > $ printf 'avahi\nblueman\nmate-menu-editor\n' |\   join -o2.2 -
> > > beehive/stats/Sisyphus-x86_64/ufb-1 |\   grep 'pygobject.*devel'
> > > python3-module-pygobject3-devel python3-module-pygobject3-devel
> > > python3-module-pygobject3-devel
> > 
> > Ну, это, наверное, потому, что всё остальное требуемое для сборки -
> > - python3-based, apt иногда делает что-то разумное и логичное.
> 
> Т.е. нам просто повезло, что по зависимости на pkgconfig(pygobject-
> 3.0) вытянулся python3-module-pygobject3-devel, а не python-module-
> pygobject3-devel.

Может и нет, у python-module-pygobject3-devel "Conflicts: python3-
module-pygobject3-devel > 3.37" и версия меньше, поскольку 3.36.x --
последняя ветка с поддержкой Python 2.


-- 
Yuri N. Sedunov

Re: [devel] I: duplicate pkgconfig() provides

[Dmitry V. Levin]

On Sun, Nov 15, 2020 at 04:14:33PM +0300, Yuri Sedunov wrote:
> В Вс, 15/11/2020 в 01:09 +0300, Dmitry V. Levin пишет:
> > On Sat, Nov 14, 2020 at 11:22:41PM +0300, Yuri Sedunov wrote:
> > > В Сб, 14/11/2020 в 22:04 +0300, Dmitry V. Levin пишет:
> > > > On Sat, Nov 14, 2020 at 08:02:46PM +0300, Yuri Sedunov wrote:
> > > > > В Сб, 14/11/2020 в 19:29 +0300, Dmitry V. Levin пишет:
> > > > > > On Sat, Nov 14, 2020 at 06:51:55PM +0300, Yuri Sedunov wrote:
> > > > > > > В Сб, 14/11/2020 в 17:59 +0300, Dmitry V. Levin пишет:
> > > > > > > > Hi,
> > > > > > > ...
> > > > > > > 
> > > > > > > > имена devel-пакетов вручную.
> > > > > > > > 
> > > > > > > 
> > > > > > > > python3-module-pygobject-devel    pkgconfig(pygobject-
> > > > > > > > 2.0)   ==2.28.6
> > > > > > > > python-module-pygobject-devel     pkgconfig(pygobject-
> > > > > > > > 2.0)   ==2.28.7
> > > > > > > > python-module-pygobject3-devel    pkgconfig(pygobject-
> > > > > > > > 3.0)   ==3.36.1
> > > > > > > > python3-module-pygobject3-devel   pkgconfig(pygobject-
> > > > > > > > 3.0)   ==3.38.0
> > > > > > > 
> > > > > > > Это всегда будут pygobject'ы второй и третьей версий, для
> > > > > > > python 2 python 3 каждый. Никаких проблем в указании
> > > > > > > конкретного *pygobject*-devel пакета в качестве сборочной
> > > > > > > зависимости никто не испытывает.
> > > > > > > 
> > > > > > > И только лишь python-module-pygtk-devel имеет
> > > > > > > автоматическую зависимость на pkgconfig(pygobject-2.0)
> > > > > > > кроме ручной на python-module-pygobject-devel.
> > > > > > > 
> > > > > > > С этим надо смириться.
> > > > > > 
> > > > > > Так, а есть ли тогда от этих pkgconfig(pygobject-2.0) и
> > > > > > pkgconfig(pygobject-3.0) хоть какая-нибудь польза?
> > > > > 
> > > > > Кроме PyGTK? -- да, бывают нужны. У тебя есть логи пересборки
> > > > > сизифа, их можно пошерстить.
> > > > 
> > > > python*-module-pygobject*-devel, конечно, присутствуют в
> > > > сборочной среде 74 пакетов, но по логам сборки не видно, нужны
> > > > были эти Provides или нет.
> > > 
> > > Видимо, надо тщательнее шерстить. Например, в mypaint среди флагов
> > > компиляции есть -I/usr/include/pygobject-3.0, что в логе сборки
> > > видно, и неспроста, в setup.py егоном есть следующий фрагмент:
> > > 
> > >     initial_deps = ["%s >= 1.6" % LIBMYPAINT]
> > >     remaining_deps = [
> > >         "pygobject-3.0",
> > >         "glib-2.0",
> > >         "libpng",
> > >         "lcms2",
> > >         "gtk+-3.0",
> > >         "mypaint-brushes-2.0",
> > >     ]
> > >     check_dependencies(initial_deps + remaining_deps)
> > 
> > Да, но setup.py не оперирует зависимостями пакетов, ему всё равно,
> > есть ли у pygobject-3.0.pc какой-нибудь Provides:
> > pkgconfig(pygobject-3.0.pc) или нет.
> 
> Неправильно понял, Подумалось, что ты хочешь вовсе лишить какие-то
> pygobject'ы pc-файлов.

Нет, конечно.  У pc-файлов и их Provides разные пространства имён: первые
видны только в установленной среде, вторые - во всём репозитории.

> Только у python-module-pygtk-devel есть зависимость на
> pkgconfig(pygobject-2.0).
> 
> Сделал тестовое задание, в котором вырезал у уходящих python-module-
> pygobject*-devel соответствующие Provides, а у python-module-pygtk-
> devel зависимость на pkgconfig(pygobject-2.0).
> 
> Устроит?

Да, вполне.

> > > > Поиск по всем спекам даёт такой результат:
> > > > 
> > > > $ git --git-dir=/people/specbot/public/specs.git grep
> > > > '^[^#]*pkgconfig(pygobject-[23]\.0)' @
> > > > @:a/avahi/avahi.spec:BuildRequires: python3-devel python3(dbus)
> > > > pkgconfig(pygobject-3.0) @:b/blueman/blueman.spec:BuildRequires:
> > > > pkgconfig(pygobject-3.0) @:m/mate-menu-
> > > > editor/mozo.spec:BuildRequires:
> > > > pkgconfig(libmate-menu) pkgconfig(pygobject-3.0)
> > > > 
> > > > Во всех трёх случаях без явного указания в спеках был каким-то
> > > > образом выбран python3-module-pygobject3-devel:
> > > > 
> > > > $ printf 'avahi\nblueman\nmate-menu-editor\n' |\   join -o2.2 -
> > > > beehive/stats/Sisyphus-x86_64/ufb-1 |\   grep 'pygobject.*devel'
> > > > python3-module-pygobject3-devel python3-module-pygobject3-devel
> > > > python3-module-pygobject3-devel
> > > 
> > > Ну, это, наверное, потому, что всё остальное требуемое для сборки -
> > > - python3-based, apt иногда делает что-то разумное и логичное.
> > 
> > Т.е. нам просто повезло, что по зависимости на pkgconfig(pygobject-
> > 3.0) вытянулся python3-module-pygobject3-devel, а не python-module-
> > pygobject3-devel.
> 
> Может и нет, у python-module-pygobject3-devel "Conflicts: python3-
> module-pygobject3-devel > 3.37" и версия меньше, поскольку 3.36.x --
> последняя ветка с поддержкой Python 2.

К тому же ещё версия pkgconfig(pygobject-3.0) у
python3-module-pygobject3-devel выше, а имя пакета лексикографически
круче, чем у python-module-pygobject3-devel.  Так что у apt всё-таки
могли бы быть логичные основания сделать этот выбор.


-- 
ldv

Re: [devel] I: duplicate pkgconfig() provides

[Vitaly Lipatov]

Dmitry V. Levin писал 14.11.20 17:59:
...
> Обратите внимание на часть этой таблицы:
> Package:                        Provide Name:              Provide 
> Version:
...
> libglusterfs7-devel             pkgconfig(libgfchangelog)  =0.0.1
> libglusterfs8-devel             pkgconfig(libgfchangelog)  =0.0.1
Эта часть таблицы отражает мнение мантейнера, что нет разницы, с какой 
из одинаковых версий собираться.
...
> Я не вижу другого выхода, кроме как запретить дублирование pkgconfig 
> provides.
Помимо устранения ошибок и путаницы это приведёт к тому, что у нас будет 
меньше разных версий одной библиотеки в репозитории (особенно для тех 
апстримов, которые не позаботились разграничить принципиально разные 
версии).

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

Re: [devel] I: duplicate pkgconfig() provides

[Aleksei Nikiforov]

03.12.2020 12:31, Andrey Cherepanov пишет:
> 16.11.2020 12:33, Vitaly Lipatov пишет:
>> Dmitry V. Levin писал 14.11.20 17:59:
>> ...
>>> Обратите внимание на часть этой таблицы:
>>> Package:                        Provide Name: Provide Version:
>> ...
>>> libglusterfs7-devel pkgconfig(libgfchangelog)  =0.0.1
>>> libglusterfs8-devel             pkgconfig(libgfchangelog) =0.0.1
>> Эта часть таблицы отражает мнение мантейнера, что нет разницы, с какой 
>> из одинаковых версий собираться.
>> ...
>>> Я не вижу другого выхода, кроме как запретить дублирование pkgconfig 
>>> provides.
>> Помимо устранения ошибок и путаницы это приведёт к тому, что у нас 
>> будет меньше разных версий одной библиотеки в репозитории (особенно 
>> для тех апстримов, которые не позаботились разграничить принципиально 
>> разные версии).
>>
> Что делать с исправлением libnetcdf11?
> 
> NEW duplicate provides detected:
>   Provide:                  Providers:
>   libnetcdf.so.11           libnetcdf11-mpi libnetcdf11-seq
>   libnetcdf.so.11()(64bit)  libnetcdf11-mpi libnetcdf11-seq
>   pkgconfig(netcdf)         libnetcdf-devel libnetcdf-mpi-devel
>          old duplicate provides resolved:
>   Provide:                  Providers:
>   libnetcdf.so.11           libnetcdf11-mpi libnetcdf11-seq
>   libnetcdf.so.11()(64bit)  libnetcdf11-mpi libnetcdf11-seq
>   pkgconfig(netcdf)         libnetcdf-devel libnetcdf-mpi-devel
> 
> 

Я думаю, стоит попробовать узнать нужны ли до сих пор mpi версии 
кому-либо. Если нет, то возможно стоит их просто удалить. Вот если 
mpi-версии нужны или удалять не хочется, то это уже будет вопрос посложнее.

> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
> 

Re: [devel] I: duplicate pkgconfig() provides

[Dmitry V. Levin]

On Thu, Dec 03, 2020 at 02:50:08PM +0300, Andrey Cherepanov wrote:
> 03.12.2020 12:54, Aleksei Nikiforov пишет:
> > 03.12.2020 12:31, Andrey Cherepanov пишет:
> >> 16.11.2020 12:33, Vitaly Lipatov пишет:
> >>> Dmitry V. Levin писал 14.11.20 17:59:
> >>> ...
> >>>> Обратите внимание на часть этой таблицы:
> >>>> Package:                        Provide Name: Provide Version:
> >>> ...
> >>>> libglusterfs7-devel pkgconfig(libgfchangelog)  =0.0.1
> >>>> libglusterfs8-devel             pkgconfig(libgfchangelog) =0.0.1
> >>> Эта часть таблицы отражает мнение мантейнера, что нет разницы, с 
> >>> какой из одинаковых версий собираться.
> >>> ...
> >>>> Я не вижу другого выхода, кроме как запретить дублирование 
> >>>> pkgconfig provides.
> >>> Помимо устранения ошибок и путаницы это приведёт к тому, что у нас 
> >>> будет меньше разных версий одной библиотеки в репозитории (особенно 
> >>> для тех апстримов, которые не позаботились разграничить 
> >>> принципиально разные версии).
> >>>
> >> Что делать с исправлением libnetcdf11?
> >>
> >> NEW duplicate provides detected:
> >>   Provide:                  Providers:
> >>   libnetcdf.so.11           libnetcdf11-mpi libnetcdf11-seq
> >>   libnetcdf.so.11()(64bit)  libnetcdf11-mpi libnetcdf11-seq
> >>   pkgconfig(netcdf)         libnetcdf-devel libnetcdf-mpi-devel
> >>          old duplicate provides resolved:
> >>   Provide:                  Providers:
> >>   libnetcdf.so.11           libnetcdf11-mpi libnetcdf11-seq
> >>   libnetcdf.so.11()(64bit)  libnetcdf11-mpi libnetcdf11-seq
> >>   pkgconfig(netcdf)         libnetcdf-devel libnetcdf-mpi-devel
> >>
> >>
> >
> > Я думаю, стоит попробовать узнать нужны ли до сих пор mpi версии 
> > кому-либо. Если нет, то возможно стоит их просто удалить. Вот если 
> > mpi-версии нужны или удалять не хочется, то это уже будет вопрос 
> > посложнее.
> >
> ACLs of affected packages (5):
>   exodusii              darktemplar @everybody
>   libcf-mpi             darktemplar @everybody
>   libnetcdf_c++-4-mpi   darktemplar @everybody
>   libnetcdf_c++4-1-mpi  darktemplar @everybody
>   libnetcdff6-mpi       darktemplar @everybody
> 
> Нужны. Я бы хотел услышать мнение ldv@.

Всему этому -mpi нужны мантейнеры, без них не нужны.


-- 
ldv

Re: [devel] I: duplicate pkgconfig() provides

[Aleksei Nikiforov]

03.12.2020 15:00, Andrey Cherepanov пишет:
> 03.12.2020 14:52, Dmitry V. Levin пишет:
>> On Thu, Dec 03, 2020 at 02:50:08PM +0300, Andrey Cherepanov wrote:
>>> 03.12.2020 12:54, Aleksei Nikiforov пишет:
>>>> 03.12.2020 12:31, Andrey Cherepanov пишет:
>>>>> 16.11.2020 12:33, Vitaly Lipatov пишет:
>>>>>> Dmitry V. Levin писал 14.11.20 17:59:
>>>>>> ...
>>>>>>> Обратите внимание на часть этой таблицы:
>>>>>>> Package:                        Provide Name: Provide Version:
>>>>>> ...
>>>>>>> libglusterfs7-devel pkgconfig(libgfchangelog)  =0.0.1
>>>>>>> libglusterfs8-devel             pkgconfig(libgfchangelog) =0.0.1
>>>>>> Эта часть таблицы отражает мнение мантейнера, что нет разницы, с
>>>>>> какой из одинаковых версий собираться.
>>>>>> ...
>>>>>>> Я не вижу другого выхода, кроме как запретить дублирование
>>>>>>> pkgconfig provides.
>>>>>> Помимо устранения ошибок и путаницы это приведёт к тому, что у нас
>>>>>> будет меньше разных версий одной библиотеки в репозитории (особенно
>>>>>> для тех апстримов, которые не позаботились разграничить
>>>>>> принципиально разные версии).
>>>>>>
>>>>> Что делать с исправлением libnetcdf11?
>>>>>
>>>>> NEW duplicate provides detected:
>>>>>    Provide:                  Providers:
>>>>>    libnetcdf.so.11           libnetcdf11-mpi libnetcdf11-seq
>>>>>    libnetcdf.so.11()(64bit)  libnetcdf11-mpi libnetcdf11-seq
>>>>>    pkgconfig(netcdf)         libnetcdf-devel libnetcdf-mpi-devel
>>>>>           old duplicate provides resolved:
>>>>>    Provide:                  Providers:
>>>>>    libnetcdf.so.11           libnetcdf11-mpi libnetcdf11-seq
>>>>>    libnetcdf.so.11()(64bit)  libnetcdf11-mpi libnetcdf11-seq
>>>>>    pkgconfig(netcdf)         libnetcdf-devel libnetcdf-mpi-devel
>>>>>
>>>>>
>>>> Я думаю, стоит попробовать узнать нужны ли до сих пор mpi версии
>>>> кому-либо. Если нет, то возможно стоит их просто удалить. Вот если
>>>> mpi-версии нужны или удалять не хочется, то это уже будет вопрос
>>>> посложнее.
>>>>
>>> ACLs of affected packages (5):
>>>    exodusii              darktemplar @everybody
>>>    libcf-mpi             darktemplar @everybody
>>>    libnetcdf_c++-4-mpi   darktemplar @everybody
>>>    libnetcdf_c++4-1-mpi  darktemplar @everybody
>>>    libnetcdff6-mpi       darktemplar @everybody
>>>
>>> Нужны. Я бы хотел услышать мнение ldv@.
>> Всему этому -mpi нужны мантейнеры, без них не нужны.
>>
>>
> Теперь хотелось бы услышать мнение darktemplar@, как автора пакетов, 
> которым нужен mpi.
> 
> 

Своё мнение я написал уже выше. Вы написали "нужны". ldv@ ввёл эту 
систему, причём даже не сделав исключения для уже существующих проблем, 
и без предложений что с этим делать в случае альтернатив. Пусть 
предложит теперь решение, или же отключит непроработанную систему.

Позволю себе процитировать:

https://lists.altlinux.org/pipermail/devel/2020-September/211797.html

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

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

> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
> 

Re: [devel] I: duplicate pkgconfig() provides

[Dmitry V. Levin]

On Thu, Dec 03, 2020 at 03:54:25PM +0300, Aleksei Nikiforov wrote:
> 03.12.2020 15:00, Andrey Cherepanov пишет:
> > 03.12.2020 14:52, Dmitry V. Levin пишет:
> >> On Thu, Dec 03, 2020 at 02:50:08PM +0300, Andrey Cherepanov wrote:
> >>> 03.12.2020 12:54, Aleksei Nikiforov пишет:
> >>>> 03.12.2020 12:31, Andrey Cherepanov пишет:
> >>>>> 16.11.2020 12:33, Vitaly Lipatov пишет:
> >>>>>> Dmitry V. Levin писал 14.11.20 17:59:
> >>>>>> ...
> >>>>>>> Обратите внимание на часть этой таблицы:
> >>>>>>> Package:                        Provide Name: Provide Version:
> >>>>>> ...
> >>>>>>> libglusterfs7-devel pkgconfig(libgfchangelog)  =0.0.1
> >>>>>>> libglusterfs8-devel             pkgconfig(libgfchangelog) =0.0.1
> >>>>>> Эта часть таблицы отражает мнение мантейнера, что нет разницы, с
> >>>>>> какой из одинаковых версий собираться.
> >>>>>> ...
> >>>>>>> Я не вижу другого выхода, кроме как запретить дублирование
> >>>>>>> pkgconfig provides.
> >>>>>> Помимо устранения ошибок и путаницы это приведёт к тому, что у нас
> >>>>>> будет меньше разных версий одной библиотеки в репозитории (особенно
> >>>>>> для тех апстримов, которые не позаботились разграничить
> >>>>>> принципиально разные версии).
> >>>>>>
> >>>>> Что делать с исправлением libnetcdf11?
> >>>>>
> >>>>> NEW duplicate provides detected:
> >>>>>    Provide:                  Providers:
> >>>>>    libnetcdf.so.11           libnetcdf11-mpi libnetcdf11-seq
> >>>>>    libnetcdf.so.11()(64bit)  libnetcdf11-mpi libnetcdf11-seq
> >>>>>    pkgconfig(netcdf)         libnetcdf-devel libnetcdf-mpi-devel
> >>>>>           old duplicate provides resolved:
> >>>>>    Provide:                  Providers:
> >>>>>    libnetcdf.so.11           libnetcdf11-mpi libnetcdf11-seq
> >>>>>    libnetcdf.so.11()(64bit)  libnetcdf11-mpi libnetcdf11-seq
> >>>>>    pkgconfig(netcdf)         libnetcdf-devel libnetcdf-mpi-devel
> >>>>>
> >>>>>
> >>>> Я думаю, стоит попробовать узнать нужны ли до сих пор mpi версии
> >>>> кому-либо. Если нет, то возможно стоит их просто удалить. Вот если
> >>>> mpi-версии нужны или удалять не хочется, то это уже будет вопрос
> >>>> посложнее.
> >>>>
> >>> ACLs of affected packages (5):
> >>>    exodusii              darktemplar @everybody
> >>>    libcf-mpi             darktemplar @everybody
> >>>    libnetcdf_c++-4-mpi   darktemplar @everybody
> >>>    libnetcdf_c++4-1-mpi  darktemplar @everybody
> >>>    libnetcdff6-mpi       darktemplar @everybody
> >>>
> >>> Нужны. Я бы хотел услышать мнение ldv@.
> >> Всему этому -mpi нужны мантейнеры, без них не нужны.
> >>
> >>
> > Теперь хотелось бы услышать мнение darktemplar@, как автора пакетов, 
> > которым нужен mpi.
> 
> Своё мнение я написал уже выше. Вы написали "нужны". ldv@ ввёл эту 
> систему, причём даже не сделав исключения для уже существующих проблем, 
> и без предложений что с этим делать в случае альтернатив. Пусть 
> предложит теперь решение, или же отключит непроработанную систему.

Извините, мне сейчас некогда.
Я считаю, что сложившаяся конфигурация с libnetcdf.so.11()(64bit) просто нерабочая:
альтернативные провайдеры soname не работают, и у нас их больше не должно быть.


-- 
ldv

Re: [devel] I: duplicate pkgconfig() provides

[Vladislav Zavjalov]

On Thu, Dec 03, 2020 at 12:54:31PM +0300, Aleksei Nikiforov wrote:
> Я думаю, стоит попробовать узнать нужны ли до сих пор mpi версии 
> кому-либо. Если нет, то возможно стоит их просто удалить. Вот если 
> mpi-версии нужны или удалять не хочется, то это уже будет вопрос посложнее.

Прошу прощения за очень медленный подход к blas/lapack. Но я по-прежнему
про него думаю и что-то пытаюсь иногда делать. Моя текущая идея - собирать
все варианты библиотек (reference, optimized, threads, mpi) из одного пакета
openblas. В нем есть все необходимое для этого, и так будет меньше шансов, что
интерфейсы разъедутся. А переключать надо, видимо, альтернативами (у меня,
впрочем, нет опыта изготовления альернатив, и до них я пока не дошел).

Вопрос, возможна ли такая схема в связи с последними новшествами?

Если придумается хороший ответ, то он подойдет и для других пакетов
с mpi-альтернативами.

Re: [devel] I: duplicate pkgconfig() provides

[Andrey Savchenko]

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

On Fri, 4 Dec 2020 12:59:31 +0300 Vladislav Zavjalov wrote:
> On Thu, Dec 03, 2020 at 12:54:31PM +0300, Aleksei Nikiforov wrote:
> > Я думаю, стоит попробовать узнать нужны ли до сих пор mpi версии 
> > кому-либо. Если нет, то возможно стоит их просто удалить. Вот если 
> > mpi-версии нужны или удалять не хочется, то это уже будет вопрос посложнее.
> 
> Прошу прощения за очень медленный подход к blas/lapack. Но я по-прежнему
> про него думаю и что-то пытаюсь иногда делать. Моя текущая идея - собирать
> все варианты библиотек (reference, optimized, threads, mpi) из одного пакета
> openblas. В нем есть все необходимое для этого, и так будет меньше шансов, что
> интерфейсы разъедутся. А переключать надо, видимо, альтернативами (у меня,
> впрочем, нет опыта изготовления альернатив, и до них я пока не дошел).
> 
> Вопрос, возможна ли такая схема в связи с последними новшествами?
> 
> Если придумается хороший ответ, то он подойдет и для других пакетов
> с mpi-альтернативами.

С MPI так просто не выйдет. Если по BLAS/LAPACK ещё есть стандарты,
которые позволяют делать переключение реализации без пересборки, то
MPI можно собрать только с конкретной версией конкретной
реализации, даже между соседними версиями они уже несовместимы. Это
большая проблема :(

Я вижу только способ по аналогии с python2/3 собирать пакеты
в разных подпакетах с разными MPI.

Best regards,
Andrew Savchenko

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

Re: [devel] I: duplicate pkgconfig() provides

[Vladislav Zavjalov]

On Fri, Dec 04, 2020 at 01:40:17PM +0300, Andrey Savchenko wrote:
> On Fri, 4 Dec 2020 12:59:31 +0300 Vladislav Zavjalov wrote:
> > On Thu, Dec 03, 2020 at 12:54:31PM +0300, Aleksei Nikiforov wrote:
> > > Я думаю, стоит попробовать узнать нужны ли до сих пор mpi версии 
> > > кому-либо. Если нет, то возможно стоит их просто удалить. Вот если 
> > > mpi-версии нужны или удалять не хочется, то это уже будет вопрос посложнее.
> > 
> > Прошу прощения за очень медленный подход к blas/lapack. Но я по-прежнему
> > про него думаю и что-то пытаюсь иногда делать. Моя текущая идея - собирать
> > все варианты библиотек (reference, optimized, threads, mpi) из одного пакета
> > openblas. В нем есть все необходимое для этого, и так будет меньше шансов, что
> > интерфейсы разъедутся. А переключать надо, видимо, альтернативами (у меня,
> > впрочем, нет опыта изготовления альернатив, и до них я пока не дошел).
> > 
> > Вопрос, возможна ли такая схема в связи с последними новшествами?
> > 
> > Если придумается хороший ответ, то он подойдет и для других пакетов
> > с mpi-альтернативами.
> 
> С MPI так просто не выйдет. Если по BLAS/LAPACK ещё есть стандарты,
> которые позволяют делать переключение реализации без пересборки, то
> MPI можно собрать только с конкретной версией конкретной
> реализации, даже между соседними версиями они уже несовместимы. Это
> большая проблема :(
> 
> Я вижу только способ по аналогии с python2/3 собирать пакеты
> в разных подпакетах с разными MPI.

Я бы сказал, что мой вопрос остается в силе,
Можно ли собрать из одного src.rpm пакеты libblas-ref, libblas-threads,
libblas-mpi (с какой-то из реализаций), с библиотеками в своих директориях
и альтернативами для их переключения?
Как это будет совмещаться с борьбой с duplicate provides?

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

С другой стороны, тут обсуждается, нужна ли нам хоть одна mpi.
Может быть, стоит оставить не больше одной, а другие предлагать сделать
желающим, в виде "карманов".

Re: [devel] I: duplicate pkgconfig() provides

[Sergey V Turchin]

On Friday, 4 December 2020 14:05:44 MSK Vladislav Zavjalov wrote:
> On Fri, Dec 04, 2020 at 01:40:17PM +0300, Andrey Savchenko wrote:
> > On Fri, 4 Dec 2020 12:59:31 +0300 Vladislav Zavjalov wrote:
> > > On Thu, Dec 03, 2020 at 12:54:31PM +0300, Aleksei Nikiforov wrote:
> > > > Я думаю, стоит попробовать узнать нужны ли до сих пор mpi версии
> > > > кому-либо. Если нет, то возможно стоит их просто удалить. Вот если
> > > > mpi-версии нужны или удалять не хочется, то это уже будет вопрос
> > > > посложнее.
> > > 
> > > Прошу прощения за очень медленный подход к blas/lapack. Но я по-прежнему
> > > про него думаю и что-то пытаюсь иногда делать. Моя текущая идея -
> > > собирать
> > > все варианты библиотек (reference, optimized, threads, mpi) из одного
> > > пакета openblas. В нем есть все необходимое для этого, и так будет
> > > меньше шансов, что интерфейсы разъедутся. А переключать надо, видимо,
> > > альтернативами (у меня, впрочем, нет опыта изготовления альернатив, и
> > > до них я пока не дошел).
> > > 
> > > Вопрос, возможна ли такая схема в связи с последними новшествами?
> > > 
> > > Если придумается хороший ответ, то он подойдет и для других пакетов
> > > с mpi-альтернативами.
> > 
> > С MPI так просто не выйдет. Если по BLAS/LAPACK ещё есть стандарты,
> > которые позволяют делать переключение реализации без пересборки, то
> > MPI можно собрать только с конкретной версией конкретной
> > реализации, даже между соседними версиями они уже несовместимы. Это
> > большая проблема :(
> > 
> > Я вижу только способ по аналогии с python2/3 собирать пакеты
> > в разных подпакетах с разными MPI.
> 
> Я бы сказал, что мой вопрос остается в силе,
> Можно ли собрать из одного src.rpm пакеты libblas-ref, libblas-threads,
> libblas-mpi (с какой-то из реализаций), с библиотеками в своих директориях
> и альтернативами для их переключения?
> Как это будет совмещаться с борьбой с duplicate provides?
Если в %_libdir будет только libblas-ref, -devel-пакет будет только один и 
остальные libblas-* будут альтернативами переключать /etc/ld.so.conf.d/
libblas.conf, то конфликтов не будет.

> Другие библиотеки и программы можно собирать точно так же, если все
> нужные для сборки пакеты и реализации можно поставить одновременно
> и переключаться между ними в процессе сборки...
> 
> С другой стороны, тут обсуждается, нужна ли нам хоть одна mpi.
> Может быть, стоит оставить не больше одной, а другие предлагать сделать
> желающим, в виде "карманов".
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel


-- 
Regards, Sergey.