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 1SHyGx-0002cr-4q for garchives@archives.gentoo.org; Wed, 11 Apr 2012 14:11:47 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 17050E0C50; Wed, 11 Apr 2012 14:11:28 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 1C25BE0C37 for ; Wed, 11 Apr 2012 14:10:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 2BD221B400F for ; Wed, 11 Apr 2012 14:10:07 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.152 X-Spam-Level: X-Spam-Status: No, score=-1.152 tagged_above=-999 required=5.5 tests=[AWL=-0.404, 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 xCn7VGuJCugc for ; Wed, 11 Apr 2012 14:09:59 +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 120641B4009 for ; Wed, 11 Apr 2012 14:09:57 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SHyF7-0005xH-U7 for gentoo-dev@gentoo.org; Wed, 11 Apr 2012 16:09:53 +0200 Received: from 91.85.60.122 ([91.85.60.122]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Apr 2012 16:09:53 +0200 Received: from slong by 91.85.60.122 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Apr 2012 16:09:53 +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: [gentoo-dev-announce] Council meeting summary for 3 April 2012 Date: Wed, 11 Apr 2012 15:13:03 +0100 Organization: Friendly-Coders Message-ID: References: <20353.41193.129711.306663@a1i15.kph.uni-mainz.de> <20120408220422.GA26440@kroah.com> <4F833687.4040004@gentoo.org> <4F8503DF.1010802@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: 91.85.60.122 X-Archives-Salt: 9832fc84-f444-4355-a05c-e17d6e2bf6a6 X-Archives-Hash: 38d2d8c132e7c54b436b9859abc2c058 Zac Medico wrote: > On 04/10/2012 07:28 PM, Steven J Long wrote: >> I suppose you could script that, but again, it just seems like a lot of >> bother to implement an "alternative" that doesn't actually gain anything >> over the traditional setup (plus making sure that partitions are mounted >> before udev starts.) > > At least in the case of udev, we gain from not having to maintain a fork. > "Making sure that partitions are mounted before udev starts" is a lot less of an ask than setting up an initramfs, and changing the way we've worked for years. It's what you proposed: an earlymounts init script, or patches to Gentoo initscripts to do the same thing. Neither involves any patches to udev proper, so no fork needs to be maintained. >> As for the burden of ensuring that binaries installed to /{s,}bin don't >> link to libs in /usr, why not just automate a QA check for that, and let >> developers decide whether a fix is necessary? After all, core packages >> that do that even when configured with prefix and execprefix = /, aren't >> so portable, and Gentoo has always championed "doing the right thing" wrt >> helping upstream fix portability issues. > > If the relevant ebuild developers really want to support that, it's fine > I guess. Hopefully that won't involve using static links as workarounds > for cross-/usr dependencies. Well I for one wouldn't like that, so no argument there: it's only for where the package would be definitely be considered for inclusion in a rescue- disk/ initramfs/ partition, like say lvm2, mount or fsck. While you might not always be able to access the manpages, a system admin would want at least the binaries available. I think it was mgorny who posted a check, which is why I brought it up. Perhaps an opt-in check if some variable is set, would be better? That way, only a maintainer who wants to mark the package as system-critical, and is happy to deal with linkage issues for binaries (including just deciding that some aren't so critical, which implies an optional exclusion variable, or listing binaries that should be checked) would set it, in the interests of overall portability and helping traditional users. If a maintainer isn't interested, or upstream don't like it (ie won't accept bugs with such a setup even when linkage is not the issue), there's no additional burden. Of course, if no developer thinks it's worth doing, the discussion is moot. It would seem at the least useful, if not necessary, however, if Gentoo is going to continue to support the traditional split /usr setup. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)