(In reply to Sergey Y. Afonin from comment #0)

> Логика может быть такой:

Хотя нет, логика поиска набора исключений должна быть сложнее. Есть kernel-image-domU-std-def, а в p9, смотрю, появились kernel-image-rt, kernel-image-lts и т.п.

Что за хвосты?

(In reply to Vitaly Chikunov from comment #2)

> Что за хвосты?

Почему-то неопакеченные файлы в /lib/modules/`uname -r` от каждого ядра, которое когда-то было установлено. Хотя, может быть, это стоит повесить на сами ядра.

Ответ на вопрос какие файлы автоматом даст ответ к кому обращаться.

Посчитал сам.

$ less orphaned.txt.gz | grep /lib/modules/
kernel-modules-nvidia-std-def   /lib/modules/5.4.32-std-def-alt1/.versions
kernel-modules-nvidia-un-def    /lib/modules/5.5.17-un-def-alt1/.versions
kernel-modules-xtables-addons-std-def   /lib/modules/5.4.32-std-def-alt1/xtables-addons
kernel-modules-xtables-addons-un-def    /lib/modules/5.5.17-un-def-alt1/xtables-addons

Последний в changelog:

kernel-modules-nvidia-std-def zerg
kernel-modules-xtables-addons-std-def rider

(In reply to Vitaly Chikunov from comment #5)

> Посчитал сам.

Это не всё. Ещё там остаются /lib/modules/`uname -r`/modules.*

(In reply to Sergey Y. Afonin from comment #6)

> Это не всё. Ещё там остаются /lib/modules/`uname -r`/modules.*

Хотя это было в std-def в p8. В p9 остаётся каталог misc, видимо от kernel-modules-e1000e-std-def. А про nvidia-std-def у меня какое-то дежавю, что я, вроде бы, про это где-то писал. Но баг что-то не вижу.

(Ответ для Vitaly Chikunov на комментарий #5)
> kernel-modules-nvidia-std-def   /lib/modules/5.4.32-std-def-alt1/.versions
> kernel-modules-nvidia-un-def    /lib/modules/5.5.17-un-def-alt1/.versions
> Последний в changelog:
> kernel-modules-nvidia-std-def zerg
Файлы в /lib/modules/[...]/.versions принадлежат моим пакетам. Каталог .versions должен принадлежать kernel-image .

> Каталог .versions должен принадлежать kernel-image .

Скажите пожалуйста, почему каталог .versions должен принадлежать пакету kernel-image?

(Ответ для Vitaly Chikunov на комментарий #9)
> Скажите пожалуйста, почему каталог .versions должен принадлежать пакету
> kernel-image?
Потому, что в этом каталоге могут лежать файлы любых других пакетов с модулями к этому ядру.

(In reply to Sergey V Turchin from comment #10)

> Потому, что в этом каталоге могут лежать файлы любых других пакетов с
> модулями к этому ядру.

а то, что e1000e использует misc, это ошибка? Впрочем, он тоже пакету с ядром не принадлежит.

(In reply to Vitaly Chikunov from comment #4)

> Ответ на вопрос какие файлы автоматом даст ответ к кому обращаться.

Проще чистить в remove-old-kernels :-)

(Ответ для Sergey Y. Afonin на комментарий #11)
> > Потому, что в этом каталоге могут лежать файлы любых других пакетов с
> > модулями к этому ядру.
> а то, что e1000e использует misc, это ошибка? Впрочем, он тоже пакету с
> ядром не принадлежит.
Причём здесь .versions?

(Ответ для Sergey Y. Afonin на комментарий #11)
> а то, что e1000e использует misc, это ошибка? Впрочем, он тоже пакету с
> ядром не принадлежит.
Если не ошибка, то его тоже надо добавить в ядро.

(In reply to Sergey V Turchin from comment #13)

> > а то, что e1000e использует misc, это ошибка? Впрочем, он тоже пакету с
> > ядром не принадлежит.

> Причём здесь .versions?

Я, вообще-то, сразу с remove-old-kernels начал, чтобы с ядрами и модулями не разьираться.

(Ответ для Sergey Y. Afonin на комментарий #15)
> Я, вообще-то, сразу с remove-old-kernels начал, чтобы с ядрами и модулями не
> разьираться.
Зачем городить лишние костыли?

(In reply to Sergey V Turchin from comment #16)

> Зачем городить лишние костыли?

С одной стороны согласен, но remove-old-kernels - это одно место, а мантейнеров всех ядер и модулей собрать можно только посредством сизифусчеки и непропуском пакетов в репозиторий. Хотя это тоже одно место.

У нас со всех сторон добавлением и удалением файлов управляет пакетный менеджер.
Всё остальное -- костыли.

(In reply to Sergey V Turchin from comment #10)
> (Ответ для Vitaly Chikunov на комментарий #9)
> > Скажите пожалуйста, почему каталог .versions должен принадлежать пакету
> > kernel-image?
> Потому, что в этом каталоге могут лежать файлы любых других пакетов с
> модулями к этому ядру.

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

Я согласен с тем, что remove-old-kernels не должен ничего лишнего удалять так как у пользователя могут быть свои, вручную собранные, модули - и он их удалит?

(Ответ для Vitaly Chikunov на комментарий #19)
> Если это стандартная директория, то где она стандартизована? Если не секрет.
А никто не говорил что это стандарт. Это было придумано в рамках извращений с nvidia, но задумана как общая директория для _любых_ модулей.

> так как у пользователя могут быть свои, вручную собранные, модули - и он их
> удалит?
С этим я согласен. Было бы неплохо, чтоб подчищал, но чужого(пакетного) не трогал.

> А никто не говорил что это стандарт.

Стандарт, видимо, слишком сильное слово, имелось ввиду договоренность, упоминание в документации, в коде, общепринятая практика.

> Это было придумано в рамках извращений с nvidia, но задумана как общая директория для _любых_ модулей.

Где про это почитать?

1. Как пакующему любые модули, хотелось бы понять, что такое '/lib/modules/*/.versions/'. Вдруг это мне тоже нужно.

Из https://www.altlinux.org/Nvidia назначение .versions (кроме того что там версия) не понятно. Для ядра эта информация там не нужна.

2. В любом случае, "любые модули" могли бы паковать эту диру тоже, не перекладывая на другие пакеты. И пока эти "любые пакеты" это только одна nvidia. Пользователь у этой диры только один.

> Это было придумано в рамках извращений с nvidia, но задумана как общая директория для _любых_ модулей.

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

(Ответ для Vitaly Chikunov на комментарий #21)
> 1. Как пакующему любые модули, хотелось бы понять, что такое
> '/lib/modules/*/.versions/'. Вдруг это мне тоже нужно.
Да по аналогии, собственно. Драйвера для ATI до этого так и не добрались.

> Из https://www.altlinux.org/Nvidia
Я там и не участвовал.

> Для ядра эта информация там не нужна.
Если я правильно понял, у ядра нет common-пакета, поэтому нужна для остальных модулей.

> 2. В любом случае, "любые модули" могли бы паковать эту диру тоже, не
> перекладывая на другие пакеты.
У нас не принято паковать один и тот же каталог в несколько пакетов.

> И пока эти "любые пакеты" это только одна nvidia.
Смысл от этого не меняется.

> Пользователь у этой диры только один.
Нет. Их прямо сейчас может стать 3, но из-за различных недостатков приходится паковать в один.

(Ответ для Vitaly Chikunov на комментарий #22)
> Судя по тому, что в пакеты с ядрами не добавлена эта дира - про эту
> договоренность никто не знает.
Нет, все забыли. Особенно, кто не знал.
Идея была vsu@alt много лет назад. Я поддержал.

(Ответ для Sergey V Turchin на комментарий #23)
> Драйвера для ATI до этого так и не добрались.
Проприетарные, которые. Это 1-й кандидат.

(In reply to Sergey V Turchin from comment #23)
> (Ответ для Vitaly Chikunov на комментарий #21)
> > 1. Как пакующему любые модули, хотелось бы понять, что такое
> > '/lib/modules/*/.versions/'. Вдруг это мне тоже нужно.
> Да по аналогии, собственно. Драйвера для ATI до этого так и не добрались.
> 
> > Из https://www.altlinux.org/Nvidia
> Я там и не участвовал.

Раз это нигде не документировано, тогда, пожалуйста, опишите своими словами, если не трудно -- в чем цель хранить там версию. Возможно, это будет полезно и для других кто не участвовал.

> > Для ядра эта информация там не нужна.
> Если я правильно понял, у ядра нет common-пакета, поэтому нужна для
> остальных модулей.

Я имел ввиду, что ядру эта информация не нужна, оно её никак не использует, для ядра эта дира с версиями, это дира с мусором.

> > 2. В любом случае, "любые модули" могли бы паковать эту диру тоже, не
> > перекладывая на другие пакеты.
> У нас не принято паковать один и тот же каталог в несколько пакетов.

vseleznv утверждает, что так делать можно. Хотелось бы разобраться между "можно" и "не принято". Перенаправил ему этот вопрос.

> > И пока эти "любые пакеты" это только одна nvidia.
> Смысл от этого не меняется.

Смысл, это то что я хочу узнать.

(Ответ для Vitaly Chikunov на комментарий #26)
> Смысл, это то что я хочу узнать.
Смысл в том, чтобы common-каталоги паковать в базовые пакеты, как filesystem, например.

(Ответ для Vitaly Chikunov на комментарий #26)
> > Если я правильно понял, у ядра нет common-пакета, поэтому нужна для
> > остальных модулей.
> Я имел ввиду, что ядру эта информация не нужна, оно её никак не использует,
> для ядра эта дира с версиями, это дира с мусором.
Если бы оно не могло работать в файлами, в ней находящимися, то да. А так оно с ними работает, соответственно, каталог для них хорошо бы предоставить.

(Ответ для Vitaly Chikunov на комментарий #26)
> Раз это нигде не документировано, тогда, пожалуйста, опишите своими словами,
> если не трудно -- в чем цель хранить там версию. Возможно, это будет полезно
> и для других кто не участвовал.
Симлинки на модули текущего ядра для возможности их переключения, т.к. патчить возможности нет по различным причинам включая проприетарность.

(In reply to Sergey V Turchin from comment #27)
> > Смысл, это то что я хочу узнать.
> Смысл в том, чтобы common-каталоги паковать в базовые пакеты, как
> filesystem, например.

Я про смысл `.versions`.

(In reply to Sergey V Turchin from comment #29)
> (Ответ для Vitaly Chikunov на комментарий #26)
> > Раз это нигде не документировано, тогда, пожалуйста, опишите своими словами,
> > если не трудно -- в чем цель хранить там версию. Возможно, это будет полезно
> > и для других кто не участвовал.
> Симлинки на модули текущего ядра для возможности их переключения, т.к.
> патчить возможности нет по различным причинам включая проприетарность.

Симлинки на модули лежат в `/lib/modules/*/nVidia/`, а `.versions/` зачем?

(Ответ для Vitaly Chikunov на комментарий #30)
> Симлинки на модули лежат в `/lib/modules/*/nVidia/`, а `.versions/` зачем?
Ой, да. В .versions лежат файлы с их версиями.
Чтоб проще было версию модуля прочесть. У нас до сих пор нет библиотеки, которая это умеет прямо из файла модуля сделать.

(In reply to Sergey V Turchin from comment #31)
> (Ответ для Vitaly Chikunov на комментарий #30)
> > Симлинки на модули лежат в `/lib/modules/*/nVidia/`, а `.versions/` зачем?
> Ой, да. В .versions лежат файлы с их версиями.
> Чтоб проще было версию модуля прочесть. У нас до сих пор нет библиотеки,
> которая это умеет прямо из файла модуля сделать.

Может хранить версии в другом месте, например в /lib/modules/nvidia/.versions? Хранение в /lib/modules/5.4.39-std-def-alt1/.versions/, конечно не ломает ядро, но к ядру отношения, всё же, не имеет.

Пример опредеелняи версии без либ:

/tmp/.private/vt/rpmpeek.u1DmFjvJ# readlink ./lib/modules/5.4.39-std-def-alt1/nVidia/nvidia.ko
../../nvidia/5.4.39-std-def-alt1-440.82
/tmp/.private/vt/rpmpeek.u1DmFjvJ# mod=$(readlink ./lib/modules/5.4.39-std-def-alt1/nVidia/nvidia.ko)
/tmp/.private/vt/rpmpeek.u1DmFjvJ# echo ${mod##*-}
440.82

Еще вариант через modinfo

# modinfo -F version /lib/modules/5.4.39-std-def-alt1/nVidia/nvidia.ko
440.82

(Ответ для Vitaly Chikunov на комментарий #34)
> Еще вариант через modinfo
Потом в C-коде парсить?

(Ответ для Vitaly Chikunov на комментарий #33)
> readlink
Имена файлов не зависят напрямую от версии. По сути совпадение.

(Ответ для Vitaly Chikunov на комментарий #32)
> /lib/modules/nvidia/.versions?
Ещё раз повторяю. Это не nvidia.

P.S.
То, что туда никто ничего не кладёт, не делает каталог "nvidia".

(Ответ для Vitaly Chikunov на комментарий #34)
> Еще вариант через modinfo
Да. Это вообще не вариант. depmod может быть ещё не сделан.

В общем, не надо ломать работающее больше 10-и лет.
Не захочет мантейнер ядра паковать, я упакую.

(Ответ для Sergey V Turchin на комментарий #23)
> > 2. В любом случае, "любые модули" могли бы паковать эту диру тоже,
> > не перекладывая на другие пакеты.
> У нас не принято паковать один и тот же каталог в несколько пакетов.
Это не так; даже для каталогов с интересными правами (не 755 root:root),
помнится, бывает.  Важно то, чтобы _все_ такие пакеты обеспечивали идентичные права на один и тот же каталог.

(Ответ для Michael Shigorin на комментарий #40)
> Это не так;
Разве что, уже не так.

> даже для каталогов с интересными правами (не 755 root:root),
> помнится, бывает.  Важно то, чтобы _все_ такие пакеты обеспечивали
> идентичные права на один и тот же каталог.
Какой самый вопиющий пример в репозитории?

(Ответ для Michael Shigorin на комментарий #40)
> > У нас не принято паковать один и тот же каталог в несколько пакетов.
> Это не так
Что это означает? Теперь все тупо пакуют любые каталоги, за которые их сборочница не пошлёт?

2 zerg@: у нас всегда было можно паковать одинаковые каталоги в разные пакеты без конфликтов при установке, если владелец, группа и режим каталога одинаковы, насколько я вообще помню.  Уточни у glebfm@ или ldv@, если не веришь.

(Ответ для Michael Shigorin на комментарий #43)
> 2 zerg@: у нас всегда было можно паковать одинаковые каталоги в разные
> пакеты без конфликтов при установке
Т.е. по барабану, в какой пакет упакован каталог, лишь бы права совпадали?

(Ответ для Sergey V Turchin на комментарий #44)
> > 2 zerg@: у нас всегда было можно паковать одинаковые каталоги в разные
> > пакеты без конфликтов при установке
> Т.е. по барабану, в какой пакет упакован каталог, лишь бы права совпадали?
Ага.  Что для 755 root:root достаточно естественно и выходит :-)

После удаления ядер в p10 остаются такие пустые папки:

/lib/modules/5.10.118-std-def-alt1/net/wireless/realtek
/lib/modules/5.10.121-std-def-alt1/net/wireless/realtek/rtlwifi
/lib/modules/5.10.126-std-def-alt1/net/wireless/realtek
/lib/modules/5.10.128-std-def-alt1/net/wireless/realtek/rtlwifi
/lib/modules/5.10.136-std-def-alt1/net/wireless/realtek/rtlwifi

Alexander Kovalev, видимо, это ошибка запаковки какого-то из модулей

  kernel-modules-rtl88x2bu-std-def
  kernel-modules-rtl8812au-std-def

В их пакеты не запакованы промежуточные директории.

на модуль.

Наверное, тогда лучше на kernel-modules-rtl88x2bu-std-def.
А сделать как у kernel-modules-rtl8821ce-std-def

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