Я ещё посмотрю в apt-scripts-nvidia -- что можно сделать попереносимее.

> Предлагаю починить или хотя бы сказать, что указать для
rpmbuiqry -qf --qf '%{ХРЕНЗНАЕТ}' /boot/vmlinuz-4.19.46-std-def-alt1`
чтоб добыть тот ID.

Ну да, я бы исходил из того, что нельзя полагаться на конкретный формат этого ID. (Как его сформирует APT, может меняться от версии к версии.)

Например, в remove-old-kernels теперь даётся команда apt-get remove kernel-image-std-def=1:4.19.46-alt1 (со знаком "равно").

(В ответ на комментарий №1)
> kernel-image-std-def=1:4.19.46-alt1 (со знаком "равно").
Для pkgfind() не работает.
В каком формате можно указать для pkgfind()?

При этом pkgfind("kernel-image-std-def#1:4.19.46-alt1@1559056711") работает

(In reply to comment #0)
> pkgfind() в скриптах перестал находить пакет ядра при агрументе вида
> kernel-image-std-def#1:4.19.46-alt1
> 
> Предлагаю починить или хотя бы сказать, что указать для
> rpmbuiqry -qf --qf '%{ХРЕНЗНАЕТ}' /boot/vmlinuz-4.19.46-std-def-alt1`
> чтоб добыть тот ID.
> 
> Конкретно, в apt-scripts-nvidia проблема.

Предлагаю присвоить значение (pkg_kernel_prov_name, pkg_kernel_prov_verstr) прямо из результата

os.getexecout("rpmquery-strictdep -f /boot/vmlinuz-" .. kernel_name)

разрезав по знаку =.

Вместо вот этого кода поиска Provides пакета с ядром (rpmquery-strictdep тоже ищет его лучший Provides):

kernel_pkg_nameversion = os.getexecout("rpmquery -f --qf '%{NAME}#%{EPOCH}:%{VERSION}-%{RELEASE}' /boot/vmlinuz-" .. kernel_name)
pkg_kernel = pkgfind(kernel_pkg_nameversion)
if pkg_kernel == nil then
    kernel_pkg_nameversion = os.getexecout("rpmquery -f --qf '%{NAME}' /boot/vmlinuz-" .. kernel_name)
    pkg_kernel = pkgfind(kernel_pkg_nameversion)
    if pkg_kernel == nil then
	apterror(_("Package not found for your current kernel ") .. kernel_name .. " .")
	return
    end
end
-- print("Kernel " .. kernel_pkg_nameversion)
pkg_kernel_name = pkgname(pkg_kernel)
pkg_kernel_ver = pkgvercur(pkg_kernel)

pkg_kernel_prov_name = {}
pkg_kernel_prov_verstr = {}
kernel_provlist = verprovlist(pkg_kernel_ver)
for i, kprov in ipairs(kernel_provlist) do
    if string.find(kprov.name, "kernel-image-", 0, true) == 1 then
	pkg_kernel_prov_name = kprov.name
	pkg_kernel_prov_verstr = kprov.verstr
	-- print("Kernel provide " .. pkg_kernel_prov_name .. "#" .. pkg_kernel_prov_verstr)
    end
end

Пример работы в p8 (пакет rpmquery-strictdep):

[root@prodesk ~]# rpmquery-strictdep -f /boot/vmlinuz-4.4.14-std-def-alt0.M80P.1 
kernel-image-std-def = 1:4.4.14-alt0.M80P.1
[root@prodesk ~]# rpmquery-strictdep -f /boot/vmlinuz-4.9.180-std-def-alt0.M80P.1 
kernel-image-std-def = 1:4.9.180-alt0.M80P.1


Пример работы в Sisyphus:

[root@prodesk /]# rpmquery-strictdep -f /boot/vmlinuz-5.0.19-un-def-alt1 
kernel-image-un-def = 1:5.0.19-alt1:sisyphus+230627.100.1.3

Пример работы в p8 в другом режиме:

[root@prodesk ~]# allow_deps_with_beginning_dot=1 rpmquery-strictdep -f /boot/vmlinuz-4.9.180-std-def-alt0.M80P.1 
.p8.231262.100.1.1-kernel-image-std-def-1:4.9.180-alt0.M80P.1  
[root@prodesk ~]# 

Я могу попробовать реализовать эту идею чуть позже.

(В ответ на комментарий №4)
> Вместо вот этого кода поиска Provides пакета с ядром (rpmquery-strictdep тоже
> ищет его лучший Provides):
1. Этот код у меня работает с момента появления пакета и я уже обновлял его в c7, например. Не хочу попасть когда-нибудь на несовместимость.
2. Ты по сути предлагаешь всё переписывать на bash.
3. Скриптинг от этого не починится. Эти идентификаторы негде не возьмёшь даже чтоб захакать.

(In reply to comment #5)
> (В ответ на комментарий №4)
> > Вместо вот этого кода поиска Provides пакета с ядром (rpmquery-strictdep тоже
> > ищет его лучший Provides):
> 1. Этот код у меня работает с момента появления пакета и я уже обновлял его в
> c7, например. Не хочу попасть когда-нибудь на несовместимость.

Я сделал rpmquery-strictdep, чтобы облегчить переносимость. (Для потребностей kernel-build-tools и rpmrebuild-arepo)

$ ls -1 /ALT/*/noarch/RPMS.classic/rpmquery-strictdep-*
/ALT/c7.1/noarch/RPMS.classic/rpmquery-strictdep-1-alt1.noarch.rpm
/ALT/c8.1/noarch/RPMS.classic/rpmquery-strictdep-1-alt1.noarch.rpm
/ALT/p8/noarch/RPMS.classic/rpmquery-strictdep-1-alt1.noarch.rpm
/ALT/Sisyphus/noarch/RPMS.classic/rpmquery-strictdep-1-alt1.noarch.rpm
$ 

> 2. Ты по сути предлагаешь всё переписывать на bash.

Та часть, которая вызывает rpm -qf и получает некую полезную информацию. (Это необязательно APT-овый идентификатор для твоего скрипта судя по нему.)

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

> 3. Скриптинг от этого не починится. Эти идентификаторы негде не возьмёшь даже
> чтоб захакать.

Судя по скрипту, нам необязательно брать эти идентификаторы. (Сконструировать --qf можно, но это будет не очень переносимо.)

Там же дальше в том куске, который я процитировал, в итоге нам интересен только Provides, который мы сравниваем с Requires пакетов с модулями. Идентификатор для других целей вроде не нужен.

    pkg_kernel_prov_name = kprov.name
    pkg_kernel_prov_verstr = kprov.verstr

(В ответ на комментарий №6)
> > 3. Скриптинг от этого не починится.
> Судя по скрипту
Нет. Я имел ввиду, что желания соваться в скриптинг apt более не предвидится с такими плясками.

> Я сделал rpmquery-strictdep, чтобы облегчить переносимость. (Для потребностей
> kernel-build-tools и rpmrebuild-arepo)
Уже хорошо.

(In reply to comment #7)
> (В ответ на комментарий №6)
> > > 3. Скриптинг от этого не починится.
> > Судя по скрипту
> Нет. Я имел ввиду, что желания соваться в скриптинг apt более не предвидится с
> такими плясками.

Со скриптингом не ожидается проблем, если в скрипте используются только внутренние сущности apt. Все такие скрипты после последних изменений будут так же хорошо работать, даже лучше (потому что verstrcmp будет правильно определять направление upgrade -- раньше он не мог учесть buildtime, хотя у нас быо позволено иметь пакеты, различающиеся только им).

Если используются не только внутренние сущности APT, то тогда ой, может не совпасть. (Я вижу другой потенциальный выход для обсуждаемого скрипта в том, чтобы делать аналог rpm -qf функциями apt, но таких мне неизвестно.)

(In reply to comment #8)
> (In reply to comment #7)
> > (В ответ на комментарий №6)
> > > > 3. Скриптинг от этого не починится.
> > > Судя по скрипту
> > Нет. Я имел ввиду, что желания соваться в скриптинг apt более не предвидится с
> > такими плясками.
> 
> Со скриптингом не ожидается проблем, если в скрипте используются только
> внутренние сущности apt. Все такие скрипты после последних изменений будут так
> же хорошо работать, даже лучше (потому что verstrcmp будет правильно определять
> направление upgrade -- раньше он не мог учесть buildtime, хотя у нас быо
> позволено иметь пакеты, различающиеся только им).

В lua, правда, кажется, не хватет помимо verstrcmp() (интерфейса к CmpVersion(), определяющего направление upgrade) аналогичного интерфейса к CheckDep() для определения удовлетворения зависимости.

(В ответ на комментарий №8)
> Я вижу другой потенциальный выход для обсуждаемого скрипта в том,
> чтобы делать аналог rpm -qf функциями apt
Для обсуждаемого скрипта я бы сразу попросил current_kernel_pkg().

А так да. pkg_by_file() и installed_kernel_pkgs() было бы прекрасно.

(В ответ на комментарий №8)
> Если используются не только внутренние сущности APT, то тогда ой, может не совпасть.
Чтобы apt обслуживал сам себя -- вообще не обязательно на lua делать, а в остальных случаях будет необходимость использования внешних сущностей.

(В ответ на комментарий №9)
> В lua, правда, кажется, не хватет помимо verstrcmp() (интерфейса к
> CmpVersion(), определяющего направление upgrade) аналогичного интерфейса к
> CheckDep() для определения удовлетворения зависимости.
Это да. Чтобы можно было определить зависимость, например, по version-release, не указывая epoch, disttag и т.д.. В spec-файле ж можно зависимости без disttag указывать.

Сделал через rpmquery-strictdep.

(В ответ на комментарий №9)
> В lua, правда, кажется, не хватет помимо verstrcmp() (интерфейса к
> CmpVersion(), определяющего направление upgrade) аналогичного интерфейса к
> CheckDep() для определения удовлетворения зависимости.
Какой-нибудь resolvedep(str1, str2), чтоб говорило больше, меньше или удовлетворяет. Причём, полагаю, именно строковые параметры, т.к. вытащить строку из зависимости легко при помощи dep.verstr .

(В ответ на комментарий №13)
> Какой-нибудь resolvedep(str1, str2), чтоб говорило больше, меньше или удовлетворяет.
Ой, в зависимости же не только версия.
lazyverstrcmp(str1, str2) :-)

(In reply to comment #12)
> Сделал через rpmquery-strictdep.

Спасибо! Добавил соотвествующий Conflicts во все новые apt (Sisyphus, p9, p8, c8.1, c7.1) вместе с копированием этого пакета в те бранчи.