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 <gentoo-dev+bounces-51393-garchives=archives.gentoo.org@lists.gentoo.org>)
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 <gentoo-dev@lists.gentoo.org>; 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 <gentoo-dev@lists.gentoo.org>; 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 <gentoo-dev@lists.gentoo.org>;
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 <gentoo-dev@gentoo.org>; Fri, 4 May 2012 14:46:00 +0000 (UTC)
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <lnx-gentoo-dev@m.gmane.org>)
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 <gentoo-dev@gentoo.org>; 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 <gentoo-dev@gentoo.org>; 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 <slong@rathaus.eclipse.co.uk>
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: <jo0q2n$ebp$1@dough.gmane.org>
References: <CAGfcS_mLRBCEuvs2gQu8Ov9XD2MoKmFjCn+giLFsLLnvikoYOw@mail.gmail.com> <jlv8e2$fdj$1@dough.gmane.org> <4F833687.4040004@gentoo.org> <jm2q2o$4n7$1@dough.gmane.org> <4F8503DF.1010802@gentoo.org> <jm43b9$a0e$1@dough.gmane.org> <4F85E21C.4060106@gentoo.org> <jmvr06$96o$1@dough.gmane.org> <CAGfcS_nPz=6kGg49kwZ-6GGAeB0fixzUQxyyXbU8-bbO0ndKng@mail.gmail.com> <jn04lk$q2i$1@dough.gmane.org> <20120423012540.GA2130@waltdnes.org>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
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
>
>> <dberkholz> who's going to either "port" udev as necessary, or maintain
>> an old version forever?
>> <Chainsaw> I will keep an old version going until the end of time.
>> <Chainsaw> 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:
>> <dberkholz> 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 ;-)