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

(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 была довольно давно.

Локально, а не в сборочнице.

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