From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1S1QIs-00035g-1G for garchives@archives.gentoo.org; Sat, 25 Feb 2012 22:41:22 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C0C89E0BF4; Sat, 25 Feb 2012 22:41:11 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id A9317E0AB4 for ; Sat, 25 Feb 2012 22:40:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 1C69A1B4003 for ; Sat, 25 Feb 2012 22:40:44 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5.5 tests=[AWL=-0.600, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cCUsJV3_A9G for ; Sat, 25 Feb 2012 22:40:38 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 1B4161B4001 for ; Sat, 25 Feb 2012 22:40:37 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1S1QI4-0001wv-Ke for gentoo-dev@gentoo.org; Sat, 25 Feb 2012 23:40:32 +0100 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 25 Feb 2012 23:40:32 +0100 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 25 Feb 2012 23:40:32 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: rfc: virtual/modutils and module-init-tools Date: Sat, 25 Feb 2012 22:40:25 +0000 (UTC) Message-ID: References: <20120225060107.GA12218@linux1> <20120225172555.GA13487@linux1> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.136 (I'm far too busy being delicious; GIT 0efefbf /st/portage/src/egit-src/pan2) Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 2b00cc13-7c9e-4c93-bf20-e8fafe8a1586 X-Archives-Hash: f30e03f7788e6be0eb7c52c2bef80650 William Hubbs posted on Sat, 25 Feb 2012 11:25:55 -0600 as excerpted: > On Sat, Feb 25, 2012 at 08:44:39AM +0000, Duncan wrote: >> You are however correct that it'll be on most systems, at least with >> udev-181, since udev won't build without kmod, now. (I found that out >> when the build broke on me due to missing kmod, as I've had udev >> unmasked for awhile and got 181 before kmod was added as a dep.) >=20 > But, one thing about kmod is that you can turn off the command line > portions of it completely on a monolythic system since udev just uses > the library. That is actually the main reason we are transitioning over > to kmod. >=20 > You do that by putting the following in /etc/portage/package.use: >=20 > sys-apps/kmod -compat -tools Good point, and I'd done exactly that. But current docs and @system assume modules, and on principles of least=20 change for both packages and docs, I kept that assumption. For advanced users with monolithic kernel systems, kmod as a udev dep and= =20 modutils removed from @system will at once be already better and worse=20 than current state, better, since a package.use entry is way less drastic= =20 than a package.provided and an @system negating packages files entries,=20 worse, since previously, no modutils package was necessary at all once=20 the appropriate portage configs were setup, but now, kmod is required for= =20 udev, as an upstream choice made for us. package.use can take care of=20 the command line stuff, but the package is still a hard dep, since udev=20 itself won't build without it. Unless of course upstream udev provides a build-time option allowing udev= =20 to be built without module support, so it doesn't link kmod at all. I've= =20 not actually investigated that, but I doubt they do. It would sure be=20 nice, tho, if they did. Has a request been made, at least? Gentoo could= =20 then expose that option as a USE flag in the routine fashion, which would= =20 make killing the kmod dep entirely possible, for those who do have=20 monolithic kernels. --=20 Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman