From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <3E9E997B.3060508@altlinux.com> Date: Thu, 17 Apr 2003 16:09:31 +0400 From: Anton Farygin Organization: ALT Linux User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.2.1) Gecko/20030210 X-Accept-Language: ru-ru, en MIME-Version: 1.0 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> In-Reply-To: X-Enigmail-Version: 0.70.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF1EF4DCB9C10FA4F3CC8F7DE" 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: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF1EF4DCB9C10FA4F3CC8F7DE Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Ed V. Bartosh пишет: > Hello, Anton > > >> Это для сборщиков-комплектаторов ядер этих пакетов десятки, это и > >> позволяет гибко комплектовать окончательные kernel-image с набором > >> нужных фич. А для юзера собственно ничего не меняется - он берет > >> понравившийся kernel-image и ставит себе. Не хочет задумываться - > >> берет std. Зато потом начинаются бонусы - обновляется какая-нибудь > >> alsa и это не повод для вытягивания нового ядра, апгрэйдится только > >> один пакет, модуль перегрузил и все. Алса - это так, игрушки. А когда > >> это, скажем, сетевые драйверы на продакшен сервере или еще что-нибудь > >> такого же плана ? > > AF> Насколько удобно будет сборщикам собирать новые пакеты с драйверами и ядра. > Не знаю. Нужно попробовать. Но, вообще, для тех драйверов, которые > выкладываются производителями железа как раз такой подход и является > более прямым, их приходится точить для сборки в составе ядра. Да, для сторонних драйверов удобнее безусловно будет собирать. Проблемы будут возникать со сборкой новых версий основных ядер. Вопрос: будут ли в репозитарии жить ядра разных версий (и должны ли?) Просто иначе процесс перехода будет затруднен тем, что не все мантейнеры смогут пользоваться репозитарием для обновления своих дополнительных пакетов с модулями ядра. > > AF> Пример - выход ядра 2.4.21-финального. Как я понимаю сейчас процесс > AF> сборки ядра будет выглядеть примерно так: > > AF> 1) Nidd собирает kernel-source и выкладывает > AF> 2) Мантейнеры соответствующих патчей начинают портировать свои патчи > AF> на новое ядро. До тех пор, пока все не запортируются - нет возможности > AF> собрать std-sub ядро > Предлагаю назвать его kernel-image-common-тра-та-та и отразить этот > факт в полиси. В случае, если такая стратегия таки будет принята. > > При переходе на новую версию сборка базы - это первоочередная задача > и все все бросают и точат свои патчи под новые сорцы. Если кто-то не > может, не успевает, то его патч подделают другие, не вижу тут проблем. ok. Только все-таки это лучше внести в правила, что бы потом без обид ;-) > AF> ставить только те пакеты с драйверами, которые необходимы. Собственно > AF> в инсталяторе есть сейчас такая штука, но она реализована в виде хаков > AF> (прямо прописаны какие пакеты устанавливать если есть потребность в > AF> определенном драйвере). Но от таблицы я бы не отказался - будет > AF> хороший помошник для авторов kernel-image. > Возможно это и так. Но у меня пока нет идей как это грамотно сделать. Скриптом естественно. rpm --filesbypkg kernel-image-2.4.21pre5-std-up-2.4.21pre5-alt1|grep modules Далее - убираем .o и путь к модулю. Получаем базу данных ;-) > > >> А если гарантированно все пакеты с железом будут проставлены ? > > AF> Тогда проблем не возникнет. Вопрос тогда в том, какой виртуальный > AF> пакет будет ставить все пакеты с железом и как сделать так, что бы все > AF> пакеты с железом пападали в список зависимостей у виртуального > AF> пакета. Желательно - автоматически ;-) > Можно. По названиям пакетов. Полуавтоматически :) Угумс. Тогда нужно будет соответственно отслеживать появление новых пакетов, содержащих модули и производить пересборку kernel-image. > > > >> И вытаскивать/устанавливать ? > > AF> Через сеть можно забирать только модули. > Тогда я не вижу принципиальных отличий от модулей в пакетах, кроме > размера. Но тут могут возникнуть другие проблемы, например с > взаимозависимостью модулей. ну это просто ;-) > > AF> По поводу репозитария драйверов - это мысли вслух. Просьба тем, кто > AF> считает это бредом - не комментировать. И так ясно, что этот путь > AF> сложен и необычен. Это как бы предложение по улучшению текущей > AF> структуры. > Если не дробить столь мелко, то такой репозиторий - это все пакеты > kernel-module-drivers-... Чем плохо ? В принципе без разницы. Но тогда нам нужно будет подробить помельче... ;-) Например: драйвера по производителям kernel-drivers-net-intel, kernel-drivers-scsi-megaraid и т.д. С дроблением замучаемся. ;-) Т.е. - получается двойная работа: 1) дробление kernel-image на мелкие пакеты 2) прописывание зависимостей 3) ведение базы <модуль> -> <пакет> Rgds, Rider --------------enigF1EF4DCB9C10FA4F3CC8F7DE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+npl/qohfd2vlwKsRArSBAJ9aA3HVOO68uUDccU9otgS54zffUgCfffBs 9aP+hx/fEEQDG6cWon3r+qY= =VxZC -----END PGP SIGNATURE----- --------------enigF1EF4DCB9C10FA4F3CC8F7DE--