BUGZILA-история про acpid

Или про то, как я три часа доставал своим багрепортом GENTOO-поддержку

Как-то недавно обнаружил проблему в unionfs. Она проявилась при попытке создать Gentoo LiveCD со слайсами (типа SLAX или MORPHIX) и openvz-ядром на борту. При попытке выдать команду
unionctl / --list
ядро паниковало.

Как оказалось, ошибка была в unionfs -- не проверял код возрата системного вызова. По совету команды openvz направил багрепорт разработчикам и через две недели пришло сообщение, что в новом unionfs баг исправлен. Круто! Это был мой первый успешный bug report. Поверил, что иногда на твои сообщения реагируют.

Ободренный первым опытом, решил внести вклад в проблему /etc/init.d/acpid и заодно приобщиться к GENTOO-bugzila (почувствовать климат GENTOO-кухни). Конкретно проблема с этим сервисом в том, что при компиляции kernel/drivers/acpi в виде модулей, после запуска сервиса система не хочет реагировать на кнопку power off без дополнительных телодвижений. Ибо указанные модули должны быть загружены до того. Но стандартные конфиги-скрипты это дело не обеспечивают.

Предложнное мной решение, которое я и послап в GENTOO-bugzila -- загружать модули в самом сервисе.
Поразила скорость реакции -- практически моментально пришло сообщение, что мой бугрепорт является клоном другого сообщения (отклоненного) и он закрыт. И как это они умудрились так быстро соотнести один буг-репорт с другим и выяснить, что это про одно и тоже.

Прочитал я про первый буг-репорт. Оказывается, он был внесен еще в конце 2005. И предлагал сделать тоже самое. По мотивам Debian. Ибо в Debian acpid-сервис при старте тоже грузит модули. Репорт отклонили с неубедительными доводами. Типа грузить модули в сервисе -- это идеологически неверно и грозит большими неприятностями. Вы лучше типа компилите модули статически. Или пропишите их загрузку в /etc/init.d/modules.autoload

Но возникает вопроос -- а чтож тогда они там стандартно не прописаны? А если прописать модули -- не будет ли ругани при загрузке для статически собранного ядра? И сколько там прописывать? Ведь ядра развиваются, количество нужных модулей может измениться, а файл-то конфигурации -- один для всех версий (мало ли какое ядро можно выбрать для загрузки в grub).

В общем, обоснование для отказа в приеме к испольнению буг-репорта 2005 года -- не убедительное.
А переоткрыть закрытый буг, как оказалосьЮ можно только тот, что сам послал. И вот в течение трех часов идет процесс: я открываю свой буг (с вопросами-пояснениями), суппорт моментально закрывает его без попытки объяснить поподробнее. Заладили одно -- твой репорт есть дубль и не имеет право существовать. Достал я чела до белого каления, совсем он почти ругаться начал Так что бросил я это беспреспективное дело.

Результат: проблема есть, проблема системного уровня. Однако в Gentoo Weakly статистике она отсутствует (формально она закрыта). И описания убедительного, почему нельзя грузить модули в сервисах -- тоже нет. И почему в /etc/init.d/autoconfig эти модули можно грузить (работает в LiveCD), а вот для загрузки с харда аналога нет.

Неправильно как-то все это. Так проблемы не решаются. Вот такая история. Да, номера ошибок 173910 и 108196 (это если кто захочет почитать оригинал истории)

Кстати, все реальные дистры на основе GENTOO используют правленный /etc/init.d/autoconfig и при загрузке с харда (первый FANTOO, BinToo). А польза ругани все же была -- до меня дошло, почему они против. Хотя и не объяснили толково. Они не против загрузки модулей в скриптах, они против, чтоб это делалось просле перехода системы на третий уровень. Но ведь никто не мешает запускать acpid на уровне boot, а не default. В общем -- мрак. Вряд ли от официальных релизов GENTOO можно ожидать нормального безгеморойного поведения. Пользуйте производные типа Sabayon, VLOS. Даже GENTOOTH от Alex Zorg (Украина) с точки зрения результата был гораздо лучше, чем официальные релизы (вот бы его версию на основе свежего портаже -- старый вариант возродить трудно).

Кстати. Линукс имени Красного Пути (rpath linux), потомок Красной Шапки -- по технологии объединил преимущества GENTOO и FEDORA. Никто не пробовал? Вот две ссылки на описание его технологий:
http://www.rpath.com/technology/techoverview http://www.rpath.com/technology/building/recipe.html
Разрази меня гром, если это не продвинутый GENTOO. Правда чтоб прочитать только -- и то не меньше недели наверно надо. Но преимуществ -- горы! Тут тебе и распрделенная разработка, и лекость создания своего дистра. Там уже целая куча возникла, в том числе AsteriskNOW, Foresight и тд Вплоть до того, что студенты для курсовых по ИТ себе дистрик забили