From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 10 Feb 2004 15:51:00 +0300 From: "Dmitry V. Levin" To: ALT Linux kernel packages development Subject: Re: [d-kernel] Q: modutils vs module-init-tools Message-ID: <20040210125100.GB3421@basalt.office.altlinux.org> Mail-Followup-To: ALT Linux kernel packages development References: <20040209171901.GS16611@osdn.org.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="A6N2fC+uXW/VQSAv" Content-Disposition: inline In-Reply-To: <20040209171901.GS16611@osdn.org.ua> X-fingerprint: 9658 398D 181B 1200 8FC5 26B8 F6F8 846B C1E2 3429 X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.4 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: Tue, 10 Feb 2004 13:20:16 -0000 Archived-At: List-Archive: List-Post: --A6N2fC+uXW/VQSAv Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit On Mon, Feb 09, 2004 at 07:19:01PM +0200, Michael Shigorin wrote: > Здравствуйте. > Сегодня на #altlinux имели место очередные прения. На сегодняшний день существуют 3 принципиально разных подхода к проблеме: 1. mu+mit под одной тонкой крышей (как у Федоры, SuSE, Debian). Это самый лёгкий в реализации и наиболее неудобный в эксплуатации вариант, который производит впечатление временного. Основное неудобство заключено в существенных различиях конфигурирования для mu и mit. 2. mu с добавлением функционала из mit (как в /pub/people/ed). Этот вариант призван существенно облегчить миграцию на 2.6 для сисадминов благодаря полной совместимости с чистым mu. Требует постоянных затрат на поддержание актуального функционала из mit. Ввиду того, что в mu и так наблюдается переизбыток функционала, шансов на то, что этот подход будет поддержан другими вендорами, мало, т.е. все затраты на поддержку лягут на ALT. 3. mit с добавлением функционала из mu (реализации нет). Этот вариант призван решить обе задачи, т.е. и облегчить миграцию с 2.4, и избавиться от лишнего функционала толстого mu. Требует постоянных затрат на поддержание актуального функционала из mit. Шансов на то, что этот подход будет поддержан другими вендорами, по-моему, больше, но только в случае, если будет предложена уже работающая реализация. Есть опасность того, что первая реализация будет плохо работать со всеми ядрами. Вариант 1. мне не нравится, делать времянку на несколько лет я бы не хотел. Вариант 2. меня устраивает больше, но текущая реализация (modutils-2.4.25-alt16) меня не устраивает: вносимые изменения содержат явные ляпы (которые мы обсудили 6-го февраля с vsu@), и мне не очевидно, что они (изменения) не портят поддержку 2.4. Думаю, что эту реализацию можно довести до ума. 2vsu: когда? Вариант 3. этот вариант теоретически лучше всех, но отсутствие рабочей реализации сводит все его преимущества на нет. 2ab: Это ведь серьёзная тема, выбор не очевиден, наших ресурсов не хватает, может, стоит обсудить в xvendor@? Возьмёшься? -- ldv --A6N2fC+uXW/VQSAv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAKNO09viEa8HiNCkRAowZAJ4/d8EONBZM6spf9ewwQWE+vICg0QCghm7S MCQ/RALTewqOsjaf7tDugJw= =/Imj -----END PGP SIGNATURE----- --A6N2fC+uXW/VQSAv--