36696 2019-04-29 05:44:28 +0300 Не обновляется с файловым конфликтом 2019-05-02 15:54:13 +0300 1 1 4 Development Sisyphus kernel-modules-virtualbox-un-def unstable all Linux NEW P3 critical --- 1 evg imz aen boyarsh glebfm greh imz iv kernelbot ldv mike rider sbolshakov shrek sin vitty vseleznv vsu vt zerg qa-sisyphus oldest_to_newest 181320 0 evg 2019-04-29 05:44:28 +0300 =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<============================================================================== 181322 1 sin 2019-04-29 10:29:59 +0300 Попробуем проверить и пересобрать. Укажите команду, которая выполнялась и привела к данной ошибке. 181324 2 ldv 2019-04-29 10:36:51 +0300 (In reply to comment #1) > Попробуем проверить и пересобрать. Укажите команду, которая выполнялась и > привела к данной ошибке. Подозреваю, что это результат пересборки в http://git.altlinux.org/tasks/archive/done/_222/227992/logs/events.11.1.log 181325 3 imz 2019-04-29 10:37:19 +0300 Обычно модули ядра не пересобирают без изменения версии-релиза ядра, но не в этом случае. Это исключительный случай. В будущем вряд ли будет повторяться. При следующей сборке ядра описанная проблема уйдёт сама собой. Объясняется тем, что 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 делать такую транзакцию.) 181326 4 imz 2019-04-29 10:47:05 +0300 (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 закоммитить, а модули не пересобирать. Всё равно пересобрались бы со следующим релизом ядра, зато жалоб не было бы... 181371 5 zerg 2019-04-30 12:32:44 +0300 (В ответ на комментарий №4) > Надо было мне лучше kernel-build-tools закоммитить, а модули не пересобирать. Я надеюсь, при обновлении модуля nvidia после попадания в репо следующего ядра я такого не отхвачу? 181382 6 imz 2019-04-30 16:19:54 +0300 (In reply to comment #5) > (В ответ на комментарий №4) > > Надо было мне лучше kernel-build-tools закоммитить, а модули не пересобирать. > Я надеюсь, при обновлении модуля nvidia после попадания в репо следующего ядра > я такого не отхвачу? Нет. Со следующим ядром будет сконструирован другой релиз пакета с модулем и apt, добавив к имени пакета #E:V-R, будет считать его другим пакетом. (dist-upgrade не покажет) Также конфликтов по файлам в нём не будет, потому для разных версий ядра модули по разным путям кладутся. 181418 7 rider 2019-05-01 10:36:51 +0300 (В ответ на комментарий №6) > (In reply to comment #5) > > (В ответ на комментарий №4) > > > Надо было мне лучше kernel-build-tools закоммитить, а модули не пересобирать. > > Я надеюсь, при обновлении модуля nvidia после попадания в репо следующего ядра > > я такого не отхвачу? > > Нет. > > Со следующим ядром будет сконструирован другой релиз пакета с модулем и apt, > добавив к имени пакета #E:V-R, будет считать его другим пакетом. (dist-upgrade > не покажет) Также конфликтов по файлам в нём не будет, потому для разных версий > ядра модули по разным путям кладутся. А если после установки каждого нового ядра делать rebuild произвольному пакету с модулем, то я правильно понимаю что эта проблема не уйдёт ? Т.е. - мы в apt сломали механизм Allow-Duplicated для тех пакетов, пересборка которых идёт без поднимания релиза. 181420 8 imz 2019-05-01 15:28:45 +0300 (In reply to comment #7) > Т.е. - мы в apt сломали механизм Allow-Duplicated для тех пакетов, пересборка > которых идёт без поднимания релиза. Да, правильно. Неочевидно, как это чинить. И потому что надо ещё понять, чего мы хотим. И потому что нет действия, "промежуточного" между rpm -i и rpm -U. Нужно ли позволять "параллельную" установку пакетов, отличающихся только disttag или buildtime? 181421 9 imz 2019-05-01 15:32:17 +0300 (In reply to comment #7) > Т.е. - мы в apt сломали механизм Allow-Duplicated для тех пакетов, пересборка > которых идёт без поднимания релиза. Так, только я бы не сказал, что мы что-то сломали. Раньше просто такой возможности не было: пересобирать в репозиторий без поднимания релиза. А как бы повели себя локально пересобранные у людей пакеты с другим buildtime, если их добавить в источники для apt и если они Allow-Duplicated, я даже не знаю. Возможно, наблюдали бы такую же картину. 181424 10 rider 2019-05-01 20:10:24 +0300 Пересборка с изменением buildtime была довольно давно. Сломали мы конечно тем, что сделали новую фичу, которая не во всех режимах поддерживается и дали простой инструмент эту фичу задействовать. 181433 11 imz 2019-05-02 15:54:13 +0300 (In reply to comment #10) > Пересборка с изменением buildtime была довольно давно. Локально, а не в сборочнице. > Сломали мы конечно тем, что сделали новую фичу, которая не во всех режимах > поддерживается и дали простой инструмент эту фичу задействовать.