From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <3E9E8891.1030903@altlinux.ru> Date: Thu, 17 Apr 2003 14:57:21 +0400 From: aen User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.3) Gecko/20030309 X-Accept-Language: ru-ru, ru 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: <3E9E7E8A.1060907@altlinux.com> X-Enigmail-Version: 0.73.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=KOI8-R; format=flowed 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: Anton Farygin пишет: > Ed V. Bartosh пишет: > >> Hello, Anton >> AF> Удобство эксплуатации - безусловно, важный момент. А о >> AF> каком удобстве _эксплуатации_ может идти речь, если >> AF> вместо одного пакета появляется десяток-другой ? >> Это для сборщиков-комплектаторов ядер этих пакетов десятки, это и >> позволяет гибко комплектовать окончательные kernel-image с набором >> нужных фич. А для юзера собственно ничего не меняется - он берет >> понравившийся kernel-image и ставит себе. Не хочет задумываться - >> берет std. Зато потом начинаются бонусы - обновляется какая-нибудь >> alsa и это не повод для вытягивания нового ядра, апгрэйдится только >> один пакет, модуль перегрузил и все. Алса - это так, игрушки. А когда >> это, скажем, сетевые драйверы на продакшен сервере или еще что-нибудь >> такого же плана ? > > > Насколько удобно будет сборщикам собирать новые пакеты с драйверами и > ядра. > > Пример - выход ядра 2.4.21-финального. Как я понимаю сейчас процесс > сборки ядра будет выглядеть примерно так: > > 1) Nidd собирает kernel-source и выкладывает > 2) Мантейнеры соответствующих патчей начинают портировать свои патчи > на новое ядро. До тех пор, пока все не запортируются - нет возможности > собрать std-sub ядро Нет. Патчи std собирает главный мейнтейнер ядра. > > 3) После портирования патчей мантейнеры ядер начинают медленно и > упорно собирать собственно сами ядра (не забыть, что еще нужно всем > владельцам пакетов kernel-feat, входящим в kernel-image > запортироваться на новое ядро (если есть необходимость)) > > Лично мне не очень нравится пункт 2, ибо тогда задержка с > портированием хоть одного мантейнера патча или функционала будет > держать всех остальных. Есть идеи, как это обойти ? Может быть > прописать в policy, что в случае задержек мантейнер ядра имеет право > пересобрать пакет с функционалом? Да. > > > >> >> AF> Необходимо будет поправить kudzu и инсталятор от MDK на >> AF> предмет использования этой таблицы при определении >> AF> устройств и установке пакетов. >> >> AF> kudzu придется править достаточно сильно. >> А если гарантированно все пакеты с железом будут проставлены ? > > > Тогда проблем не возникнет. Вопрос тогда в том, какой виртуальный > пакет будет ставить все пакеты с железом и как сделать так, что бы все > пакеты с железом пападали в список зависимостей у виртуального пакета. > Желательно - автоматически ;-) Да, я об этом писал. Не знаю только, надо ли это включать в policy. > > Rgrds, Алексей