From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Mailer: Gnus v5.8.8/XEmacs 21.4 - "Portable Code" X-Comment-To: Anton Farygin To: devel-kernel@altlinux.ru Subject: Re: [d-kernel] kernel policy References: <20030415144045.GA13440@shamrock.office.altlinux.ru> <87he8zljh6.fsf@velvet.po.cs.msu.su> <3E9C5571.2040009@altlinux.ru> <3E9D746E.5040006@altlinux.ru> <3E9E4517.3070500@altlinux.com> <3E9E6A76.6050402@altlinux.com> <3E9E7E8A.1060907@altlinux.com> <3E9E997B.3060508@altlinux.com> In-Reply-To: <3E9E997B.3060508@altlinux.com> From: ed@altlinux.ru (Ed V. Bartosh) Organization: ALT Linux Date: 17 Apr 2003 15:56:54 +0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Sender: devel-kernel-admin@altlinux.ru Errors-To: devel-kernel-admin@altlinux.ru X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: devel-kernel@altlinux.ru List-Unsubscribe: , List-Id: ALT Linux kernel packages development List-Post: List-Help: List-Subscribe: , List-Archive: Archived-At: List-Archive: List-Post: Hello, Anton >> Не знаю. Нужно попробовать. Но, вообще, для тех драйверов, которые >> выкладываются производителями железа как раз такой подход и является >> более прямым, их приходится точить для сборки в составе ядра. AF> Да, для сторонних драйверов удобнее безусловно будет AF> собирать. Проблемы будут возникать со сборкой новых версий основных AF> ядер. Вопрос: будут ли в репозитарии жить ядра разных версий (и должны AF> ли?) Думаю да. Если на основе репозитария планируется собирать ядра для разных дистрибутивов, то без этого не обойтись. AF> ставить только те пакеты с драйверами, которые необходимы. Собственно AF> в инсталяторе есть сейчас такая штука, но она реализована в виде хаков AF> (прямо прописаны какие пакеты устанавливать если есть потребность в AF> определенном драйвере). Но от таблицы я бы не отказался - будет AF> хороший помошник для авторов kernel-image. >> Возможно это и так. Но у меня пока нет идей как это грамотно сделать. AF> Скриптом естественно. AF> rpm --filesbypkg kernel-image-2.4.21pre5-std-up-2.4.21pre5-alt1|grep AF> modules AF> Далее - убираем .o и путь к модулю. Получаем базу данных ;-) :) Грабли будут. Ладно, этот путь все равно не принимается для данного репозитария, завязываем. Но по мне, так тут грабель просто поля будут. AF> пакет будет ставить все пакеты с железом и как сделать так, что бы все AF> пакеты с железом пападали в список зависимостей у виртуального AF> пакета. Желательно - автоматически ;-) >> Можно. По названиям пакетов. Полуавтоматически :) AF> Угумс. Тогда нужно будет соответственно отслеживать появление новых AF> пакетов, содержащих модули и производить пересборку kernel-image. Да, но это уже будет решать мэнтейнер этого kernel-image. Не хочет - не пересобирает. AF> В принципе без разницы. Но тогда нам нужно будет подробить AF> помельче... ;-) Например: драйвера по производителям AF> kernel-drivers-net-intel, kernel-drivers-scsi-megaraid и т.д. Жизнь покажет, может даже и kernel-module-drivers-net-e100, полиси не противоречит :) AF> С дроблением замучаемся. ;-) Т.е. - получается двойная работа: 1) AF> дробление kernel-image на мелкие пакеты 2) прописывание зависимостей AF> 3) ведение базы <модуль> -> <пакет> Результирующий kernel-image не дробиться будет, а составляться из kernel-image-common и kernel-modules, или ты о другом ? -- Best regards, Ed V. Bartosh