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 1SQJnS-0003DW-1h for garchives@archives.gentoo.org; Fri, 04 May 2012 14:47:50 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E8C66E06C8; Fri, 4 May 2012 14:47:17 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 52D5DE06C1 for ; Fri, 4 May 2012 14:46:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id ACE7B1B403B for ; Fri, 4 May 2012 14:46:07 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5.5 tests=[AWL=-0.381, BAYES_00=-1.9, RCVD_NUMERIC_HELO=1.164, 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 jLJcXxFXuBO3 for ; Fri, 4 May 2012 14:46:01 +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 CCCE71B4036 for ; Fri, 4 May 2012 14:46:00 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SQJlc-0004Lv-UG for gentoo-dev@gentoo.org; Fri, 04 May 2012 16:45:56 +0200 Received: from 91.85.61.115 ([91.85.61.115]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 May 2012 16:45:56 +0200 Received: from slong by 91.85.61.115 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 May 2012 16:45:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steven J Long Subject: [gentoo-dev] Re: Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 Date: Fri, 04 May 2012 15:50:24 +0100 Organization: Friendly-Coders Message-ID: References: <4F833687.4040004@gentoo.org> <4F8503DF.1010802@gentoo.org> <4F85E21C.4060106@gentoo.org> <20120423012540.GA2130@waltdnes.org> 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="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 91.85.61.115 X-Archives-Salt: 2136a8dd-f4b1-449b-81e8-eccab6de90eb X-Archives-Hash: d7a44b22f14c9dd3e45603a4225a5e3c Walter Dnes wrote: > Steven J Long wrote > >> who's going to either "port" udev as necessary, or maintain >> an old version forever? >> I will keep an old version going until the end of time. >> dberkholz: My plan is to patch reasonable behaviour back into >> udev, and going with the upstream releases as long as it is feasible. > > I use busybox's mdev, and it works fine for my simple system. Does it handle USB and other media hotplug? That's the real killer for desktops. (Running scripts in response to events is another issue, and what has led to the udev problem.) > >> To confirm again, that this is about without initramfs: >> sure i can. maintain old udev-XXX forever, put an elog in new >> udev that says "if you want separate /usr without initramfs, install old >> udev, mask new, or whatever" > > systemd and udev are being merged into one tarball. For the > "foreseeable > future", it will still build 2 separate binaries. What happens down the > road if/when it all becomes one combined binary? > Well I've read assertions that it will be possible to build udev without systemd for distros and users who want it, and this is supposedly a firm commitment into the future. Then again, experience doesn't bode well for those kind of commitments. (It's much easier to introduce coupling between software in the same package. GregKH has also mooted a tightly-coupled "core" Linux distro, which afaict is the same reasoning as GnomeOS, and /that/ sounds like a clusterfsck waiting to happen.) >> And again, I ask: if it were *not* about running udev without an >> initramfs, then why would anyone even be discussing the possibility >> of patching or forking? > > Forking/patching udev would be a major undertaking. The point I was making was that it couldn't even be an issue, _unless_ one were talking about an install without an initramfs, since udev with an initramfs supports a split /usr. (That's required for the usr-bin merge to be useful, since the idea is to enable snapshotting of all distribution binaries; after years of rubbishing any possible reason admins might have for a split /usr, it's now critical to a major 'new' feature of Fedora, and all the traditional benefits are selling-points of the "new design".) As for the effort, so long as you don't need udev to create nodes for localmount, you don't need an initramfs with either our patched approach, or an earlymounts initscript, and now there's vapier's busybox applet to do the mounts for you. None of which require any modification to udev, nor maintenance of an initrd and the binaries therein. Regards, Steve. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)