[devel] E: incoming x86_64 reject: kernel-modules-fglrx-wks-smp-1.0.8.47.1-alt1.132626.2

Eugine Kosenko =?iso-8859-1?q?eugine=2Ekosenko_=CE=C1_gmail=2Ecom?=
Сб Мар 22 15:41:13 MSK 2008


2008/3/7, Konstantin A. Lepikhov <lakostis на altlinux.org>:
>  Friday 07, at 03:14:55 PM you wrote:
>  > On Fri, Mar 07, 2008 at 03:11:11PM +0300, Konstantin A. Lepikhov wrote:
>  > > Friday 07, at 03:02:18 PM you wrote:

>  > > > kernel-image-wks-smp-2.6.18-alt2 ушел в orphaned через год после того как
>  > > > пролежал в Сизифе без изменений.

В связи с этим несколько более практических вопросов:

1. На какое ядро идеологически спрыгивать с wks-smp рабочим станциям,
т.е., системам, где не планируется использовать заморочки типа pae,
ovz и т.п.? Я так понял, std-smp? Или std-def? Естессно, у меня обе
машины одноядерные. Желательно, чтобы при этом работали модули типа
alsa.

2. Вообще странно, что из репозитария был исключен
kernel-headers-modules-wks-smp, но оставлен kernel-image-wks-smp. В
результате я вообще ничего не знал об изменении до получения письма из
QA о том, что мой модуль не собрался по означенной причине. Я так
понял, надо бы и образ выкинуть из Сизифа, раз заголовки модулей ушли.
Ну и заодно предупредили бы тех, кто еще сидит на этом ядре, что пора
мигрировать. Так? Если так, то почему это не было сделано?

3. Я в некотором роде тоже пострадавший -- мой модуль usb-rndis-lite
не собирается. Хотелось бы узнать у знающих людей, как идеологически
правильно собирать сторонние модули, чтобы они не были жестко
привязаны к модификациям ядра. Я так понял, правильное решение --
мультипакет? И что, отслеживать все такие ситуации вручную?


Подробная информация о списке рассылки Devel