From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Comment-To: Anton Farygin To: ALT Linux kernel packages development Subject: Re: [d-kernel] I: new packages to sisyphus In-Reply-To: <3F28E060.3030408@altlinux.com> (Anton Farygin's message of "Thu, 31 Jul 2003 13:24:48 +0400") References: <200307311020.45053.darkstar@altlinux.ru> <3F28E060.3030408@altlinux.com> From: ed@altlinux.ru (Ed V. Bartosh) Organization: ALT Linux Date: Thu, 31 Jul 2003 13:01:22 +0400 Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.2 Precedence: list Reply-To: ALT Linux kernel packages development List-Id: ALT Linux kernel packages development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2003 10:02:34 -0000 Archived-At: List-Archive: List-Post: >>>>> "AF" == Anton Farygin writes: >> ARV> c8b4ca3389c7859a6a4de0efb2cea2c9 >> ARV> kernel-feat-drivers-net-3c90x-2003.07.30-alt1.src.rpm >> ARV> Драйвер для карт 3COM 3x90x >> darkstar-alt> ed_: привет! >> darkstar-alt> ed_: по поводу 3c90x - а зачем его в отдельный >> darkstar-alt> пакет? ed_: ему лучше всего в основном ядре жить >> darkstar-alt> ))) >> Ему лучше жить в kernel-module и >> darkstar-alt> апгрейдиться отдельно от ядра. >> По-моему это уже >> darkstar-alt> обсуждалось и неоднократно. >> AF> А зачем ? AF> Давайте представим себе труд мантейнера ядра, которому нужно AF> собрать новую версию пакета kernel-image: AF> 1) Собирает kernel-source Не помню когда я делал это последний раз. 2) Собирает kernel-image, ставит в AF> сборочную систему хедеры 3) Пересобирает 15-20 пакетов с AF> модулями, одновременно правя спеки, прописывая зависимости на AF> новое ядро и т.д. Это просто нужно автоматизировать, вот и все. AF> Мне откровенно жаль этого мантейнера. мне тоже, если это делать руками. Никто же не спорит о необходимости этот процесс автоматизировать. AF> По моему изначально мы некоторое время обсуждали следущую AF> идеологию: AF> 1) Есть std ядро, включающее в себя все что мы считаем стабильно AF> работающим. Как то: дополнительные драйвера, исправления ошибок, AF> файловые системы и т.д. 2) Все остальные пакеты, дополняющие AF> или изменяющие функциональность в std-up ядре базируются AF> исключительно на нем и на его наборе патчей. Как-то w4l, rsbac, AF> ядра с supermount и т.д. AF> По моему - будет намного удобнее и менее запутаннее чем в AF> текущей ситуации... Единственное что нам нужно сделать - это AF> добится максимально качественного std-up ядра. По-моему мы также обсуждали преимущества подхода, при котором мы имеем как можно больше функционала в отдельных пакетах с модулями. И особых возражений не было. Он имеет как минимум 2 достоинства: не нужно пересобирать ядро при изменениях в этих пакетах, либо добавлении новых и не нужно перегружать систему при их установке/апгрейде. Для серверных конфигураций это очень важно. Я предлагаю таки доопределиться со стратегией выноса в модули и зафиксировать ее в полиси. -- Best regards, Ed V. Bartosh