From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <3E92D82B.6070009@altlinux.com> Date: Tue, 08 Apr 2003 18:09:47 +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] Daedalus kernel References: <3E92C2D3.2070903@altlinux.com> <3E92CDF6.1040907@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="------------enigE727561B27DD7DDD5E596C1D" 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) --------------enigE727561B27DD7DDD5E596C1D Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Ed V. Bartosh пишет: > > AF> Вот такое разбиение, например, для начала: > > AF> kernel-patches-new-drivers - содержит новые драйвера > AF> kernel-patches-bugfixes-drivers - содержит исправления для > AF> существующих драйверов > > AF> kernel-patches-security - включает в себя secrurity-fixes > AF> kernel-patches-update-drivers - содержит в себе обновления для > AF> драйверов до новых версий. > > AF> далее по такому-же принципу ;-) > > AF> Т.е. - бить или нет по категориям я бы не стал. По моему с железом все > AF> достаточно прозрачно и если патч не вносит изменения никуда, кроме > AF> кода самого драйвера - то его вполне можно включать всегда. > Зачем так зажимать схему ? Это вариант, противоположный вынесению > каждого патча в отдельный пакет. Я считаю, что нужен компромисс, то > есть в данном случае все-таки группировка по категориям. > Если мне, например, не нужны патчи, касающиеся видео, или, скажем > ide, то я и не буду их прикладывать. Тем более, что частенько они > правят не только свой код. > Мне кажется, что некая гибкость в этом деле не помешает. > > Предлагаю для железных патчей категории по принципу схемы > каталогов в сорцах: > kernel-patches-drivers-net > kernel-patches-drivers-scsi > kernel-patches-drivers-ide > kernel-patches-net > kernel-patches-fs > > И подкатегории fixes, updates, new, как Вы предлагаете. > > Точно так же можно поступить и с остальными, зачем велосипед > изобретать, если в ядре уже есть устоявшаяся иерархия. Хм... наверное это правильно - идти по иерархии в ядре, но как быть с особо тяжелыми случаями, когда необходимо наложить часть патчей на scsi и часть патчей на net ? Или особо тяжелые случаи - в морг ? ;-) Rgds, Rider --------------enigE727561B27DD7DDD5E596C1D 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+ktgvqohfd2vlwKsRAuFsAJ9vnVwH3HdzbUTH/r0hRZKws7wbwwCggGJ1 2pZfTLFMZU39sqc/lwBpXzM= =iJBD -----END PGP SIGNATURE----- --------------enigE727561B27DD7DDD5E596C1D--