Bug 45082

(Ответ для ruslandh на комментарий #0)
> Файл с blacklist конфликтует при обновлении пакета. 
> Возможно в этом случае файлу надо было дать другое имя.
ЕМНИП конфликта бы не было, если бы _содержимое_ файла было одинаково
в обоих законфликтовавших пакетах; там действительно было важное изменение?

Сравнивая спеки в p10 и sisyphus
https://packages.altlinux.org/ru/p10/srpms/kernel-modules-bcmwl-std-def/specfiles/

в файл добавлена строчка с модулуь ядра
 
blacklist brcmfmac

Возможно в спеке достаточно убрать noreplace

"
%config(noreplace) %_sysconfdir/modprobe.d/blacklist-bcm.conf
%config(noreplace) %_sysconfdir/modprobe.d/blacklist-bcm2.conf
"

в пакетах с модулями нельзя паковать ничего кроме модулей, т.к. у них allow duplicate стоит в true. всё остальное надо выносить в common пакеты.

(In reply to Anton Farygin from comment #4)
> надо выносить в common пакеты.
Только, проблема у этих common-пакетов, что они потом остаются в системе, т.к. никем не выносятся. :-(

(In reply to Sergey V Turchin from comment #5)
> (In reply to Anton Farygin from comment #4)
> > надо выносить в common пакеты.
> Только, проблема у этих common-пакетов, что они потом остаются в системе,
> т.к. никем не выносятся. :-(

apt-get autoremove?

(In reply to Dmitry V. Levin from comment #6)
> apt-get autoremove?
Ааа, ну да. Теперь так можно.

Если бы в bkacklist можно было указать конкретное ядро, можно было бы и в каждый blacklist-ядро.conf паковать.

Или хотя бы иметь каталог /etc/modprobe-ядро.d/

(In reply to Sergey V Turchin from comment #8)
> Или хотя бы иметь каталог /etc/modprobe-ядро.d/
Была такая идея и даже патчи, кстати:
https://lore.kernel.org/linux-modules/20200226133221.44342a57@table.localdomain/

v3 тоже был, но без ответа.  Видимо, на этом всё и остановилось.
https://lore.kernel.org/linux-modules/20200227174635.5a2b13c9@boyarsh.office.basealt.ru/

(In reply to ruslandh from comment #0)
> Created attachment 12389 [details]
> Вид ошибки при обновления ядра командой update-kernel
> 
> Файл с blacklist конфликтует при обновлении пакета. 
> Возможно в этом случае файлу надо было дать другое имя.
> Извинте за фото.

Не извиню ) Что и с чем конфликтует? Из флуда далее я ничего не понял.

(In reply to Gleb F-Malinovskiy from comment #10)
> v3 тоже был, но без ответа.  Видимо, на этом всё и остановилось.
> https://lore.kernel.org/linux-modules/20200227174635.5a2b13c9@boyarsh.office.
> basealt.ru/

Да странно, Lucas De Marchi сначала говорит "I really like the idea of supporting this", а потом игнорирует v3. (ps. Хотя, commit message мог бы быть с обоснованием (примером), а не просто отсылкой, что оно где-то есть "In some cases it looks reasonable".)

А не проще-ли тогда создавать блеклисты в %post и удалять в %preun ? 
Не очень красиво, но зато нет конфликта.

Но идея иметь  /etc/modprobe-ядро.d/ мне сама по себе нравится. Уже сталкивался с тем, что после обновлении ядра переставала работать сеть именно по этой причине. Старое ядро имело работало с одним модулем ядра , а в новом ядре использовался другой модуль. И блеклист от старого ядра блокировал работу модуля из нового ядра.

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

So what does this mean to an end user? Will an update fix this bug? Or will the user have to manually intervene to fix this?

My knowledge of Russian language is нуль and I'm not a huge fan of translation services so please bear with my ignorance if the answers to my questions have already been discussed here.

Thanks.

kernel-source-bcmwl-6.30.223.271-alt6.g6adc981 -> sisyphus:

 Wed Apr 05 2023 L.A. Kostis <lakostis@altlinux.ru> 6.30.223.271-alt6.g6adc981
 - Add kernel-module configuration subpkg (closes #45082).

Отлично ;-)

Спасибо. Нас сколько я понимаю, отдельный пакет для конфига решает проблему изменения конфига в будущем, но не конфликт, который создало прошлое изменение (актуальный для тех у кого был установлен старый пакет и они делают апдейт).

Проблема осталась. Конфликт переместился в bcmwl-kernel-conf, у которого не выставлены:
Conflicts: kernel-modules-bcmwl-std-def < 6.30.223.271-alt14
Conflicts: kernel-modules-bcmwl-un-def < 6.30.223.271-alt14
Conflicts: kernel-modules-bcmwl-centos < 6.30.223.271-alt14

Выставление конфликтов не поможет, а только усугубит ситуацию.
Надо убрать зависимость на пакет с конфигами из модулей.

kernel-modules-bcmwl-un-def-6.30.223.271-alt15.393992.1 -> sisyphus:

 Thu Jun 15 2023 Anton Farygin <rider@altlinux> 6.30.223.271-alt15.393992.1
 - Build for kernel-image-un-def-6.3.8-alt1.
 Thu Jun 15 2023 Anton Farygin <rider@altlinux.ru> 6.30.223.271-alt15
 - remove kernel-modules-bcmwl-un-def-kernel-conf requires to avoid conflicting configuration with
   old bcmwl modules (closes: #45082)

(In reply to Anton Farygin from comment #20)
> Выставление конфликтов не поможет, а только усугубит ситуацию.

Почему? По идее удалит старый модуль и всё.

(In reply to Anton Farygin from comment #20)
> Выставление конфликтов не поможет, а только усугубит ситуацию.
> Надо убрать зависимость на пакет с конфигами из модулей.

Давайте сначала определимся, какую проблему мы пытаемся решить? Данное изменение сделает модуль неработоспособным "из коробки", т.к. необходимая конфигурация ядра будет отсутствовать.

kernel-modules-bcmwl-un-def-6.30.223.271-alt15.393504.1 -> p10:

 Thu Jun 15 2023 Anton Farygin <rider@altlinux> 6.30.223.271-alt15.393504.1
 - Build for kernel-image-un-def-6.1.32-alt1.
 Thu Jun 15 2023 Anton Farygin <rider@altlinux.ru> 6.30.223.271-alt15
 - remove kernel-modules-bcmwl-un-def-kernel-conf requires to avoid conflicting configuration with
   old bcmwl modules (closes: #45082)

Сейчас мы решаем проблему обновляемости.

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

Я думаю что если очень хочется сделать конфиг, то оптимальный вариант - генерить его в post-скриптах пакета common и таскать в виде %ghost

(In reply to Anton Farygin from comment #25)
> Я думаю что если очень хочется сделать конфиг, то оптимальный вариант -
> генерить его в post-скриптах пакета common и таскать в виде %ghost

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

Да, можно и так.
Но вообще конечно конфиг как по мне должен быть отдельно от модулей - кому надо тот включит. Но я не знаю, как себя ведёт модуль установленный в систему - там же blacklist идёт чему-то.

Поэтому чем хорош будеть filetrigger - конфиг можно генерить только точно зная, что железка в системе есть.

(In reply to Anton Farygin from comment #27)
> Поэтому чем хорош будеть filetrigger - конфиг можно генерить только точно
> зная, что железка в системе есть.

WiFi от broadcom может быть в виде USB-шного донгла, не воткнутого в момент установки пакета.

(In reply to Anton Farygin from comment #25)
> Установленные конфликты могут привести к непредсказуемому поведению APT,
> который ориентируется на весовые алгоритмы при расчёте своего поведения -
> какой вес перевесит то и будет делать - или удалять старые пакеты или не
> устанавливать новые с ошибкой.

Может я и не прав, так как не имею такого богатого опыта. Но, на сколько я знаю (и сталкивался с этим) эта проблема с весами может быть при dist-upgrade, но так как модули не ставятся через dist-upgrade, то её не будет — при install (который делает update-kernel) Conflict сработает.

(In reply to Gleb F-Malinovskiy from comment #26)
> По идее же можно добавить конфиг, который не будет пересекаться по именам с
> конфигами, которые были в предыдущих версиях модуля.

Гениально!

ps. Есть еще вариант с %pretrans, но Глебу он не нравится, да и переименовать конфиг проще.