=8<============================================================================== Совершаем изменения... Подготовка... #################################################################################################### [100%] файл /lib/modules/5.0.9-un-def-alt1/misc/vboxdrv.ko из устанавливаемого пакета kernel-modules-virtualbox-un-def-5.2.26-alt1.327689.1.x86_64 конфликтует с файлом из пакета kernel-modules-virtualbox-un-def-5.2.26-alt1.327689.1.x86_64 файл /lib/modules/5.0.9-un-def-alt1/misc/vboxnetadp.ko из устанавливаемого пакета kernel-modules-virtualbox-un-def-5.2.26-alt1.327689.1.x86_64 конфликтует с файлом из пакета kernel-modules-virtualbox-un-def-5.2.26-alt1.327689.1.x86_64 файл /lib/modules/5.0.9-un-def-alt1/misc/vboxnetflt.ko из устанавливаемого пакета kernel-modules-virtualbox-un-def-5.2.26-alt1.327689.1.x86_64 конфликтует с файлом из пакета kernel-modules-virtualbox-un-def-5.2.26-alt1.327689.1.x86_64 файл /lib/modules/5.0.9-un-def-alt1/misc/vboxpci.ko из устанавливаемого пакета kernel-modules-virtualbox-un-def-5.2.26-alt1.327689.1.x86_64 конфликтует с файлом из пакета kernel-modules-virtualbox-un-def-5.2.26-alt1.327689.1.x86_64 файл /lib/modules/5.0.9-un-def-alt1/misc/vboxguest.ko из устанавливаемого пакета kernel-modules-virtualbox-addition-un-def-5.2.26-alt4.327689.1.x86_64 конфликтует с файлом из пакета kernel-modules-virtualbox-addition-un-def-5.2.26-alt4.327689.1.x86_64 =8<==============================================================================
Попробуем проверить и пересобрать. Укажите команду, которая выполнялась и привела к данной ошибке.
(In reply to comment #1) > Попробуем проверить и пересобрать. Укажите команду, которая выполнялась и > привела к данной ошибке. Подозреваю, что это результат пересборки в http://git.altlinux.org/tasks/archive/done/_222/227992/logs/events.11.1.log
Обычно модули ядра не пересобирают без изменения версии-релиза ядра, но не в этом случае. Это исключительный случай. В будущем вряд ли будет повторяться. При следующей сборке ядра описанная проблема уйдёт сама собой. Объясняется тем, что apt следует настройке Allow-Duplicate для пакетов с модулями и при установке этого пакета выполняет rpm -i, а не rpm -U (чтобы не снести другие релизы). Хорошего исправления внутри apt не ожидается. Есть такое предложение, что Вы сейчас можете сделать: rpm -e kernel-modules-virtualbox-addition-un-def-5.2.26-alt4.327689.1 apt-get install kernel-modules-virtualbox-addition-un-def (Для общего решения можно было бы научить apt делать такую транзакцию.)
(In reply to comment #2) > (In reply to comment #1) > > Попробуем проверить и пересобрать. Укажите команду, которая выполнялась и > > привела к данной ошибке. > > Подозреваю, что это результат пересборки в > http://git.altlinux.org/tasks/archive/done/_222/227992/logs/events.11.1.log Надо было мне лучше kernel-build-tools закоммитить, а модули не пересобирать. Всё равно пересобрались бы со следующим релизом ядра, зато жалоб не было бы...
(В ответ на комментарий №4) > Надо было мне лучше kernel-build-tools закоммитить, а модули не пересобирать. Я надеюсь, при обновлении модуля nvidia после попадания в репо следующего ядра я такого не отхвачу?
(In reply to comment #5) > (В ответ на комментарий №4) > > Надо было мне лучше kernel-build-tools закоммитить, а модули не пересобирать. > Я надеюсь, при обновлении модуля nvidia после попадания в репо следующего ядра > я такого не отхвачу? Нет. Со следующим ядром будет сконструирован другой релиз пакета с модулем и apt, добавив к имени пакета #E:V-R, будет считать его другим пакетом. (dist-upgrade не покажет) Также конфликтов по файлам в нём не будет, потому для разных версий ядра модули по разным путям кладутся.
(В ответ на комментарий №6) > (In reply to comment #5) > > (В ответ на комментарий №4) > > > Надо было мне лучше kernel-build-tools закоммитить, а модули не пересобирать. > > Я надеюсь, при обновлении модуля nvidia после попадания в репо следующего ядра > > я такого не отхвачу? > > Нет. > > Со следующим ядром будет сконструирован другой релиз пакета с модулем и apt, > добавив к имени пакета #E:V-R, будет считать его другим пакетом. (dist-upgrade > не покажет) Также конфликтов по файлам в нём не будет, потому для разных версий > ядра модули по разным путям кладутся. А если после установки каждого нового ядра делать rebuild произвольному пакету с модулем, то я правильно понимаю что эта проблема не уйдёт ? Т.е. - мы в apt сломали механизм Allow-Duplicated для тех пакетов, пересборка которых идёт без поднимания релиза.
(In reply to comment #7) > Т.е. - мы в apt сломали механизм Allow-Duplicated для тех пакетов, пересборка > которых идёт без поднимания релиза. Да, правильно. Неочевидно, как это чинить. И потому что надо ещё понять, чего мы хотим. И потому что нет действия, "промежуточного" между rpm -i и rpm -U. Нужно ли позволять "параллельную" установку пакетов, отличающихся только disttag или buildtime?
(In reply to comment #7) > Т.е. - мы в apt сломали механизм Allow-Duplicated для тех пакетов, пересборка > которых идёт без поднимания релиза. Так, только я бы не сказал, что мы что-то сломали. Раньше просто такой возможности не было: пересобирать в репозиторий без поднимания релиза. А как бы повели себя локально пересобранные у людей пакеты с другим buildtime, если их добавить в источники для apt и если они Allow-Duplicated, я даже не знаю. Возможно, наблюдали бы такую же картину.
Пересборка с изменением buildtime была довольно давно. Сломали мы конечно тем, что сделали новую фичу, которая не во всех режимах поддерживается и дали простой инструмент эту фичу задействовать.
(In reply to comment #10) > Пересборка с изменением buildtime была довольно давно. Локально, а не в сборочнице. > Сломали мы конечно тем, что сделали новую фичу, которая не во всех режимах > поддерживается и дали простой инструмент эту фичу задействовать.