[devel] По поводу зависимостей kernel-headers-* и kernel-headers-modules-*

[Evgeny Sinelnikov]

3 октября 2008 г. 1:36 пользователь Led <ledest на gmail.com> написал:
> On Thursday, 02 October 2008 23:59:30 Konstantin Baev wrote:
>> Led пишет:
>> > Пользователи не собирают модули для старых ядер.
>>
>> Хорошо бы, только неизвестно, какое у них там ядро. Мы поддерживаем
>> максимальное количество ядер. Но даже если ядро от хедера отличается
>> всего на 1 релиз - то или ядро обновлять или старый хедер из архива
>> вытягивать, потому что он сам заместился новым.
>>
>> Или я так ужасно коряво объясняю или старожилы devel@ привыкли отвечать
>> на вопросы ответами-штампами, не особо задумываясь над конкретным случаем.
>
> Вы выдаёте свои кастомные проблемы разработчика за проблемы пользователей. При
> этом непонятно, что за проблемы, потому как непонятно для кого вы собираете
> ядерные модули: если для конечных пользователей, то зачем пользователям
> модули для старого ядра? и что это за конечные пользователи, которые сидят на
> Сизифе?

Причём тут Сизиф? На бранчах ядра тоже обновляются... Вот пример.
Ставим систему, где ядро altX, потом обновляем из бранча, где уже
altX+1... B вот тут нам понадобился новый модуль... Но собрать его мы
без прибегания к таким обходным путям, как архив, уже никак простым
путём не получится...

Да, конечно модуль мы руками не собираем, мы запускаем некий скрипт,
который это делает, ну, на худо конец пару пакетов ставим и
инклюдниками ядра... Только инклюдники-то уже не те... Вот и
выкручивайся...

> ИМХО вы придумали надуманную проблему: "всё время делаю dist-upgrade на
> автомате, но ядро не обновляю принципиально". Честно - за 10 лет в линуксе
> первый раз про такое слышу:)
>

Проблема вполне конкретная и я уже вёл речь о её причинах.... У нас
относительно небольшое community и серъёзные вендоры не смотрят на
нас, как на потенциальных клиентов... Поэтому мы собираем все модули к
своим ядрам сами и не можем предложить пользователям наших решений
возможность воспользоваться стандратными средствами сборки модулей от
тех же nvidia-дров или модулей от VMWare...

Я не умоляю достоинства некоторых технических аспектов наших решений,
а хочу указать на то, что очень даже странно, что живя "10 лет в
линуксе" вы в первый раз слышите о проблемах сборки модулей...

> Не наезд:)
>

Даже не знаю :)

> P.S. сам (для себя) поддерживаю два ядра с одинаковым flavour, но с разными
> версиями (2.6.22 и 2.6.25). Когда пришлось собирать модуль в хост системе для
> 2.6.22 и обнаружил, что установлены headers от 2.6.25 (естественно) -
> продаунгредил headers до 2.6.22 и поставил их Hold - всё это заняло минуту и
> даже в голову не пришло, что это - проблема, потому как абсолютно осознано -
> это мой, очень редкий, кастомный, абсолютно нетипичный случай, я абсолютно
> отдавал себе отчёт в том, что то, что я хочу сделать (при установленных двух
> ядрах разных версий в системе собирать что-то не в хэшере, а в
> хост-системе) - самый настоящий костыль. Т.е. попытайтесь находить ошибки
> пержде всего в своём подходе к сборке, а не в системе:)
>

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

Я вот честно и искренне заявляю, что поставить что-то на hold для
большинства пользователей десктопов задача из ряда вон... И если этого
можно избежать, то так и нужно делать...

Чтобы не переливать из пустого в порожнее... Я бы очень попросил
вынести настройки apt в отдельный подпакет, чтобы вот эту часть можно
было заменять в своих решениях:
$ rpm -qf /etc/apt/apt.conf
apt-0.5.15lorg2-alt20
[sin на server tmp]$ cat /etc/apt/apt.conf
/*
 * This is the main configuration file for the APT suite of tools,
 * see apt.conf(5) for details.
 */

// See apt-cdrom(8) for details.
Acquire::CDROM::Copy-All "false";
Acquire::CDROM::mount "/media/cdrom";

RPM
{
        Allow-Duplicated {
                // Old-style kernels.

"^(NVIDIA_)?(kernel|alsa)[0-9]*(-adv|-linus)?($|-up|-smp|-secure|-custom|-enterprise|-BOOT|-tape|-aureal)";
                // New-style kernels.
                "^kernel-(image|modules)-.*";
        };
        Hold {
                // Old-style kernels.
                "^(kernel|alsa)[0-9]+-source";
        };
};


-- 
Sin (Sinelnikov Evgeny)