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 1SLnSd-0006M7-Gm for garchives@archives.gentoo.org; Sun, 22 Apr 2012 03:27:39 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 44A5FE0B7E; Sun, 22 Apr 2012 03:27:24 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id A25B3E0A59 for ; Sun, 22 Apr 2012 03:26:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 2B7711B40EA for ; Sun, 22 Apr 2012 03:26:47 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.825 X-Spam-Level: X-Spam-Status: No, score=-1.825 tagged_above=-999 required=5.5 tests=[AWL=-1.077, 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 kdD5bieNWNYR for ; Sun, 22 Apr 2012 03:26:40 +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 D9AE71B40E9 for ; Sun, 22 Apr 2012 03:26:39 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SLnRZ-0004Ds-H1 for gentoo-dev@gentoo.org; Sun, 22 Apr 2012 05:26:33 +0200 Received: from 109.176.242.43 ([109.176.242.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Apr 2012 05:26:33 +0200 Received: from slong by 109.176.242.43 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Apr 2012 05:26:33 +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: [gentoo-dev-announce] Council meeting summary for 3 April 2012 Date: Sun, 22 Apr 2012 04:30:20 +0100 Organization: Friendly-Coders Message-ID: References: <20353.41193.129711.306663@a1i15.kph.uni-mainz.de> <20120408220422.GA26440@kroah.com> <4F833687.4040004@gentoo.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: 109.176.242.43 X-Archives-Salt: 945bfc7d-e6df-4ef0-984e-1700990f8fa9 X-Archives-Hash: 7fb017c2144286947782c4f984a9f664 Rich Freeman wrote: > On Wed, Apr 11, 2012 at 11:09 AM, Steven J Long wrote: >> That might be true for some Linux-only packages, but I really find it >> hard to believe that any upstream targetting more than one OS (just >> adding a BSD is enough) with software that could be considered critical >> (I for one would include all POSIX utilities as well as basic stuff like >> mount, fsck and lvm2) would want to ignore this kind of thing; if the >> build-system is ignoring configuration, it's a bug. > > The issue is that if udev requires libfoo, then libfoo must not be in > /usr. If libfoo is libx11 or dbus or some other complex library, that > will pull in a bunch of other stuff as well. However, I doubt that > the maintainers of all those libraries would consider them > boot-essential, so they may not be inclined to make the move. > > Obviously we're not there now, but it is a possible consequence of > moving in this direction. > Sure, but I'm curious: how would you set up an initramfs under those conditions? Where I'm going with this, is that in both cases (an initramfs or a traditional rootfs system) we need to be aware of what libs pull in what. Given that, there is actually common work both sides need. If we could focus on that, we'd all actually be cooperating to fix things for both setups, instead of arguing about which is best. :) > Keep in mind that systemd in particular does not aim to be > cross-platform - they advertise this as one of their core features. > Since tight integration is their goal that could slowly bring in a lot > of other stuff. The main platform pushing it along is Fedora, and > they're aiming to move everything into /usr, so this is a non-issue > for them. > I have a feeling that "integration" is being used as an excuse to avoid thinking about coupling and cohesion. >> I read the decision from the Council to be "we will continue to support >> the traditional split /usr eg with lvm, and no initramfs" and a Council >> member put himself forward to maintain patches to udev to ensure that >> going forward, since it is needed in his employment. >> >> Given that we can do it with initscripts, and don't need to fork udev at >> all, what's the problem? > > I can't really comment on what the decision from the Council actually > was. Well, I've stated that several times now, and included the snippet from the log where Betelgeuse specifically asked Chainsaw to clarify that a "universal" minimal initramfs was not good enough, which was confirmed. If Council members disagree with that interpretation, I'd welcome their clarification. Split /usr with lvm was specifically discussed as a use-case, since it has been outlined in Gentoo documentation. > However, maintaining patches to udev is effectively the same > thing as forking it. Right now it probably isn't hard, and over time > that could change. > > The only time patches != fork is if the patches have been submitted > upstream and are likely to be merged. > udev != openrc or any other init system, which is what we are patching[1] so that udev is not started til after localmount, should the user set a currently unsupported udev.conf option (initramfs="no"). We're only making minor shell-script modifications to udev and udev-mount initscripts, not openrc itself. Earlymounts[2] is simply an additional initscript. IOW no patches to udev whatsoever, so no fork. > In any case, it isn't a crisis now and waiting a little to see which > way the wind ends up blowing probably makes sense. > No indeed: those of us who wish to stay with our traditional setup, who have already configured our machines to localmount with built-in modules, can use the patched initscripts/earlymounts. What we'd like is for those, or equivalent functionality, to be maintained within Gentoo so we don't have to tweak patches whenever udev-init-scripts is updated, or in the earlymounts case there appear to be more issues, and those could use input from devs imo. I prefer the patched approach, even if it is a bit more setup and I am biased, since it appears to have less potential for interaction with other stuff: if you never needed an initramfs before, and can localmount with just kernel-created device-nodes (eg: you need to change fstab from using /dev/vg/lv to /dev/mapper/vg-lv for lvm), then you're fine. [1] http://forums.gentoo.org/viewtopic-t-901206.html [2] http://forums.gentoo.org/viewtopic-t-918466.html -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)