From: Anton Farygin <rider@altlinux.com> To: devel-kernel@altlinux.ru Subject: Re: [d-kernel] kernel policy Date: Thu, 17 Apr 2003 16:09:31 +0400 Message-ID: <3E9E997B.3060508@altlinux.com> (raw) In-Reply-To: <m3adep9zvr.fsf@altlinux.ru> [-- Attachment #1: Type: text/plain, Size: 4216 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]
next prev parent reply other threads:[~2003-04-17 12:09 UTC|newest] Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-04-15 14:40 nidd 2003-04-15 13:56 ` Sviatoslav Sviridov 2003-04-15 16:05 ` [d-kernel] " Sergey Vlasov 2003-04-15 15:36 ` [d-kernel] " Ed V. Bartosh 2003-04-15 18:10 ` Peter Novodvorsky 2003-04-15 18:54 ` aen 2003-04-16 7:50 ` Ed V. Bartosh 2003-04-16 15:19 ` aen 2003-04-16 14:31 ` Ed V. Bartosh 2003-04-17 6:09 ` Anton Farygin 2003-04-17 7:32 ` Ed V. Bartosh 2003-04-17 8:48 ` Anton Farygin 2003-04-17 8:49 ` Ed V. Bartosh 2003-04-17 10:14 ` Anton Farygin 2003-04-17 10:34 ` Ed V. Bartosh 2003-04-17 12:09 ` Anton Farygin [this message] 2003-04-17 11:56 ` Ed V. Bartosh 2003-04-17 13:14 ` Peter Novodvorsky 2003-04-17 10:57 ` aen 2003-04-17 13:16 ` Dmitry V. Levin 2003-04-17 12:36 ` Ed V. Bartosh 2003-04-17 13:12 ` Peter Novodvorsky 2003-04-17 13:24 ` Ed V. Bartosh 2003-04-17 14:41 ` aen 2003-04-17 14:18 ` aen 2003-04-17 10:49 ` Dmitry V. Levin 2003-04-17 10:58 ` [JT] " Anton Farygin 2003-04-17 10:50 ` Ed V. Bartosh 2003-04-17 12:11 ` Anton Farygin 2003-04-17 11:22 ` Dmitry V. Levin 2003-04-17 11:21 ` Anton Farygin 2003-04-24 23:59 ` Michael Shigorin 2003-04-17 10:43 ` Dmitry V. Levin 2003-04-17 10:16 ` Ed V. Bartosh 2003-04-17 13:09 ` Dmitry V. Levin 2003-04-17 12:25 ` Ed V. Bartosh 2003-04-24 23:57 ` Michael Shigorin 2003-04-25 9:35 ` Ed V. Bartosh 2003-04-25 10:41 ` Michael Shigorin 2003-04-25 9:45 ` Ed V. Bartosh 2003-04-25 12:04 ` Michael Shigorin 2003-04-25 11:17 ` Ed V. Bartosh 2003-04-25 13:26 ` Michael Shigorin 2003-04-25 14:34 ` Ed V. Bartosh 2003-04-16 7:44 ` Ed V. Bartosh 2003-04-16 9:28 ` aen 2003-04-16 8:58 ` Ed V. Bartosh 2003-04-16 10:08 ` Peter Novodvorsky 2003-04-16 10:39 ` aen 2003-04-16 10:31 ` Ed V. Bartosh 2003-04-16 9:36 ` Dmitry V. Levin 2003-04-16 10:13 ` Sergey Bolshakov 2003-04-16 10:45 ` aen 2003-04-16 10:01 ` Peter Novodvorsky 2003-04-16 10:15 ` Ed V. Bartosh 2003-04-16 22:10 ` Dmitry V. Levin 2003-04-17 7:21 ` Ed V. Bartosh 2003-04-17 9:21 ` aen 2003-04-17 9:35 ` Peter Novodvorsky 2003-04-17 10:47 ` Ed V. Bartosh 2003-04-17 11:29 ` Dmitry V. Levin 2003-04-17 11:36 ` Sergey Pinaev 2003-04-17 11:55 ` aen 2003-04-15 16:14 ` aen 2003-04-15 16:35 ` [d-kernel] " Vitaly Ostanin 2003-04-15 18:29 ` Peter Novodvorsky 2003-04-15 16:46 ` [d-kernel] " aen 2003-04-16 0:32 ` Denis Smirnov 2003-04-16 2:48 ` Albert R. Valiev 2003-04-16 7:47 ` Ed V. Bartosh 2003-04-16 9:28 ` aen 2003-04-16 8:47 ` aen 2003-04-16 8:42 ` Albert R. Valiev 2003-04-25 0:13 ` Michael Shigorin 2003-04-25 6:12 ` Sviatoslav Sviridov/Lintec Project 2003-04-25 6:41 ` Albert R. Valiev 2003-04-25 6:58 ` Sviatoslav Sviridov/Lintec Project 2003-04-25 6:59 ` Albert R. Valiev 2003-04-16 10:26 ` [d-kernel] " Vitaly Ostanin 2003-04-17 11:34 ` [d-kernel] " Dmitry V. Levin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=3E9E997B.3060508@altlinux.com \ --to=rider@altlinux.com \ --cc=devel-kernel@altlinux.ru \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux kernel packages development This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel-kernel/0 devel-kernel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel-kernel devel-kernel/ http://lore.altlinux.org/devel-kernel \ devel-kernel@altlinux.org devel-kernel@altlinux.ru devel-kernel@altlinux.com public-inbox-index devel-kernel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git