Bug 36150

Значит, либо репозиторий не подключен, либо драйвера для этого ядра в нём нет.

(In reply to comment #1)
> Значит, либо репозиторий не подключен, либо драйвера для этого ядра в нём нет.

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

У меня воспроизводится на любой машине с сизифом.

(В ответ на комментарий №2)
> ядерный модуль точно есть в репозитории.
https://packages.altlinux.org/ru/sisyphus/srpms/kernel-image-std-def
Нет такого ядра и модулей к нему, соответственно.

Похоже, apt поломали.

почему apt ?

Новый rpm изгадил Provides своими новыми фишками.

Но более новый rpm может это зачистил, имей это ввиду.

Не зачистил. Я не вижу разницы.

Я должен был, по идее.

Не Я должен был, а он должен был, извините.

если rpm везде зачищает disttag, то наверное и в apt-scripts эти версии должны попадать в очищенном виде.

(In reply to comment #3)
> У меня воспроизводится на любой машине с сизифом.

Какой версии rpm и apt?

скрипт nvidia-install-driver из какого пакета?

(In reply to comment #12)
> Какой версии rpm и apt?

$ rpm -qi rpm
Name        : rpm
Version     : 4.13.0.1
Release     : alt6
DistTag     : sisyphus+221238.100.2.1
Architecture: x86_64

$ rpm -qi apt
Name        : apt
Version     : 0.5.15lorg2
Release     : alt61
DistTag     : sisyphus.218765.400
Architecture: x86_64

> 
> скрипт nvidia-install-driver из какого пакета?

$ rpm -qf /usr/bin/nvidia-install-driver 
nvidia_glx_common-410.93-alt211.x86_64

(В ответ на комментарий №12)
> скрипт nvidia-install-driver из какого пакета?
Из пакета apt-scripts-nvidia.
verprovlist() возвращает список Provides, не почищенный от disttags.

*** Bug 36159 has been marked as a duplicate of this bug. ***

Кому, на ваш взгляд, следует чистить disttag, и почему?

(В ответ на комментарий №16)
> Кому, на ваш взгляд, следует чистить disttag,
libapt перед передачей в интерпретатор.

> и почему?
Скрипты не должны зависеть от изменений внутренностей rpm.
Например, если я ставлю в pkg1.spec
Requires: pkg2 = 1.0-alt1
, то у меня никакие distag не фигурируют.
Так же должно быть и при написании скрипта.
А disttag -- внутренняя кухня rpm.

(In reply to comment #17)
> А disttag -- внутренняя кухня rpm.

Нет, это не так, disttag - это такая же внутренняя кухня, как и epoch.
epoch может не быть, и disttag может не быть.
epoch надо учитывать, если она есть, и disttag надо учитывать, если он есть.

disttag есть только у нас, следовательно, извращаться, опять же, не как у всех придётся.

Получается, что зависимости на подпакет вида
Requires: %name-common = %EVR
все неправильные и должны быть исправлены на 
Requires: %name-common = %EVRD
?

P.S.
Про
Requires: %name-common
знаю.

(In reply to comment #20)
> Получается, что зависимости на подпакет вида
> Requires: %name-common = %EVR
> все неправильные и должны быть исправлены на 
> Requires: %name-common = %EVRD
> ?

Нет, от этих двух форм эффект одинаковый.

Почему возникла такая мысль, что зависимость одной из этих форм не годится? Для каких целей?

(В ответ на комментарий №21)
> Нет, от этих двух форм эффект одинаковый.
А в скриптах разный. Там "==" не умеет учитывать disttag.
Или там есть функция сравнения версий, учитывающая disttag?

В скриптах apt? apt про это ещё может вообще не знать, если он не пользуется функциями из rpm. Просто его ещё не доделали.

К тому же я не знаю, подразумевается ли, что == сравнивает аргументы просто как строки или по особому обрабатывает версии. Тут, конечно, согласен, напрашивается специальная функция для сравнения версий типа rpmRangesOverlap() из rpm.

(В ответ на комментарий №23)
> В скриптах apt? apt про это ещё может вообще не знать, если он не пользуется
> функциями из rpm. Просто его ещё не доделали.
Ааа, тогда ждем.

> подразумевается ли, что ==
Не. Это я поторопился. Там есть verstrcmp(arg1, arg2).
При этом arg1 может быть получен из Requires, а arg2 из Provides.
rpm такое разрулит, а verstrcmp нет. Не будут они равны(теперь с disttag).

Было такое. Решил обновлением ядра из того же репозитория, откуда обновлял драйвер.

(у меня возникла другая, не связанная ошибка - оказалось, в 64-битном драйвере битые файлы - решение указал в ответе https://bugzilla.altlinux.org/show_bug.cgi?id=15326#c7 )

Уже давно захакано в nvidia-install-driver.