|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Michael Shigorin 2:5020/400 02 Apr 2003 16:07:06
To : Victor Dronov
Subject : Re: любителям сравнивать дистрибутивы
--------------------------------------------------------------------------------
Victor Dronov <victor.dronov@attbi.com> wrote:
> MS> Hу не понимаю я таких стенаний. Это вообще проблема поставщика
> MS> дистрибутива как бы.
> У вас Slackware? Вопросов больше не имею.
Ага, и в подписи mike@slack. Для любителей отвечать в сонном виде :)
> Вот для вас тот .run и сделан.
Можно, но неудобно. Я уже было начал прикидывать и этот случай, но
порождать два _разных_ (и не до такой степени зависимых) пакета из
одного архива -- неприятное занятие.
> Все остальные, пожалуйста, расскажите, какие меры предпринимает
> поставщик Вашего дистрибутива, чтобы быть уверенным, что у Вас всегда
> есть NVIDIA_kernel, собранный для всех установленных ядер.
Я все-таки позволю себе отнестись к "остальным" (бишь неслакваристам) и
заодно предложить прогуляться на ftp.altlinux.ru.
> Hint #1: ядра могут ставится из rpm (или
> какой-там-у-Вас-packge-manager).
Это самый.
> Hint #2: rpm ядра не обязательно выпущен поставщиком Вашего ядра.
В таком случае он, как правило, собран системным администратором,
которому может быть неизлишне "просто добавить воды" и получить рабочий
комплект, а не ковыряться с.
Hint: у меня именно так и обстоит. Вопросы? :)
> P.S. вот кто мне расскажет, как _автоматически_ (триггерами,
> скриптами, чертом лысым) обеспечить, чтобы всегда существовали только
> работающие комбинации kernel, NVIDIA_kernel, и NVIDIA_GLX -- выставлю
> пиво (реально, а не виртуально). То есть, одно решение я знаю: шибко
> "умный" триггер в rpm, еще идеи есть?
Код в триггере собирать/ставить, конечно, можно... в 4.1 можно даже в
пакет попробовать, доступ к базе вроде дали.
Hо с меня хватает того, что для каждого установленного в системе ядра
есть адекватный NVIDIA_kernel-версиюрек, соответствующий одному
установленному в системе NVIDIA_GLX. При этом ядерных модулей может
быть несколько, пакеты не пересекаются.
Зажимать кросс-зависимости более жестко можно попытаться, но не вижу
особого смысла и удобства в этом. Увижу -- в том дистрибутиве, которым
я пользуюсь, по крайней мере обсудится вариант реализации.
Из прикладных проблем -- 1.0-3* и 1.0-4*, т.к. изменилось название
модуля. Устраивать кашу с проверкой как-то не хотелось, когда выпускал
свою сборку 3123 для ядер ALM2.2{,-updates}, бо возни много, шансов
промазать -- тоже, а делалось ровно для тех, кому 4191 доставляли больше
проблем.
Хотя если верить ченжлогу 4349 -- проблему с несколькими серверами
должны были пофиксить. Выпускали бы RC, что ли -- а то осенью пишешь,
весной получаешь...
--
---- WBR, Michael Shigorin <mike@altlinux.ru>
------ Linux.Kiev http://www.linux.kiev.ua/
--- ifmail v.2.15dev5
* Origin: osdn.org.ua (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
