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 1SHz9m-0005GI-41 for garchives@archives.gentoo.org; Wed, 11 Apr 2012 15:08:26 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6D533E0CA5; Wed, 11 Apr 2012 15:08:04 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 8DC73E0C98 for ; Wed, 11 Apr 2012 15:06:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 208391B4002 for ; Wed, 11 Apr 2012 15:06:46 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.148 X-Spam-Level: X-Spam-Status: No, score=-1.148 tagged_above=-999 required=5.5 tests=[AWL=-0.400, 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 9Thbt4hHOBw8 for ; Wed, 11 Apr 2012 15:06:39 +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 C8FCA1B4003 for ; Wed, 11 Apr 2012 15:06:38 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SHz7t-0000vg-Kx for gentoo-dev@gentoo.org; Wed, 11 Apr 2012 17:06:29 +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 17:06:29 +0200 Received: from slong by 91.85.60.122 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Apr 2012 17:06:29 +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 16:09:36 +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: 91.85.60.122 X-Archives-Salt: fff152db-2ceb-4655-9599-691d617cb3f7 X-Archives-Hash: 5a5e73ca060c2e9b41f4badacae1c309 Rich Freeman wrote: > On Tue, Apr 10, 2012 at 10:28 PM, Steven J Long > wrote: >> 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. > > The only issue with that logic is that upstream is perfectly aware of > what they're doing already, and bugs are likely to be closed as > WONTFIX. It would only be for packages that are specifically marked, the ones you'd want in an initramfs. The "fix" is simply making sure the buildsystem doesn't look in /usr/lib etc when so marked, and checking that binaries don't link from / to anywhere but /lib*. If they do, it's up to the maintainer as to whether it's an issue. You'd only file an upstream bug if the build-system was looking in /usr/lib despite being told not to (eg when only given -L /lib.) Making sure libs are available in the right location is down to the distro, same as for the initramfs. > So, all the QA checks would do is ensure that we slowly > start maintaining forks of more and more packages. Right now the > problem is probably manageable, but I'm not convinced it will stay > that way. Once upstream developers consider all constraints to be > removed on their dependencies you could see a lot of stuff getting > pulled into root if you tried to enforce this rule. > 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. Regardless of how Linux might move (and personally I think there is a lot more opposition to this than devs realise, as it throws the idea behind userspace compatibility completely out of the window, in that it massively impacts a generation of *nix working practices, even before one considers systemd's single-point of kitchen-sink failure) taking away choice from end- users for no appreciable gain in functionality or efficiency seems like a bad idea. I understand that the argument is "this is more efficient for our development" but we're not talking about every package in the tree. Just the binaries we might need in an initramfs; making sure their linkage is sound, is likely to be useful for that case too, since it's an even more restricted environment. Wrt constraints on dependencies being removed, I don't really see that as upstream's job; they simply specify the dependencies required and where they actually are is up to the distro, and provided to the build by a mechanism like pkg-config, or just flags from the package manager. Distros always have been about managing dependencies for us. > In any case, it sounds like the directive is to keep limping along for > a while longer, 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? It would only be for users who specifically opt in, knowing that they don't need udev to localmount, and with the awareness that they might need to configure things-- which any Gentoo user is used to hearing and evaluating. > and that makes sense anyway until docs/etc are > improved. I agree with Ralph's suggestion that the newer initramfs > tools should be stabilized as well. > No argument on either of those. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)