From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 0E21859CAF for ; Fri, 8 Apr 2016 07:58:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AF8BB21C082; Fri, 8 Apr 2016 07:58:43 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id ACEC021C032 for ; Fri, 8 Apr 2016 07:58:42 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aoRJQ-0002wu-Lw for gentoo-dev@lists.gentoo.org; Fri, 08 Apr 2016 09:58:40 +0200 Received: from ip98-167-165-199.ph.ph.cox.net ([98.167.165.199]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Apr 2016 09:58:40 +0200 Received: from 1i5t5.duncan by ip98-167-165-199.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Apr 2016 09:58:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: usr merge Date: Fri, 8 Apr 2016 07:58:35 +0000 (UTC) Message-ID: References: <57067172.49cbca0a.693b1.ffff9909@mx.google.com> <20160407154636.GA26596@whubbs1.gaikai.biz> <5706A7A6.3080402@iee.org> <57070bbd.9a48620a.a07cf.3177@mx.google.com> <57070c95.0714320a.ed102.1995@mx.google.com> <570718F5.3040904@iee.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=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip98-167-165-199.ph.ph.cox.net User-Agent: Pan/0.141 (Tarzan's Death; GIT fb7f2ee) X-Archives-Salt: 3e5b03a7-bf21-4e03-9c36-f0d532844b93 X-Archives-Hash: fc24ea90f17f4670932d88abd1330002 M. J. Everitt posted on Fri, 08 Apr 2016 03:35:33 +0100 as excerpted: > On 08/04/16 02:42, William Hubbs wrote: >> The default installation location of all coreutils binaries is >> /usr/bin, then we move everything around in the ebuild. >> We are deviating from upstream in this example. >> > I would expect this isn't the only example of this in Gentoo .. we > customise the packages to make sense to the Gentoo distro, not conform > to a multitude of random "standards" applied by many developers. So, > whilst I accept that its desirable to match 'upstream' - this isn't > always going to be possible. Agreed, and moreso, while gentoo does try to stay close to upstream in general, I'd argue that paths aren't the place to do that. Instead, for paths, we should be sticking as close to FHS, XDG/freedesktop.org, etc, as makes sense (and in general it's reasonable and /does/ make sense, tho when the specs are designed with for instance binary distros in mind, they don't always). Because there are specs, but upstreams may do all sorts of random things in terms of path, some of which aren't going to work particularly well on gentoo or other distros attempting to stay at least reasonably close to FHS and XDG/freedesktop.org specs. > I would also re-iterate, as I'm sure you're aware .. there ARE > differences between sbin and bin .. unless of course you spend all your > time in a Rooted VM where it doesn't matter if you accidentally trash > your system. Some of us maintain a sensible user/superuser distinction > for a variety of reasons, and simplifying your filesystem to suit some > particular package style doesn't really sound like good reasoning for > causing a lot of headaches for maintainers and a distro overall. But... the real important distinction in terms of user vs. superuser executables is file ownership and permissions, not the directory they're in. As long as the ownership and permissions are correct, the user can only run what they are supposed to, regardless of whether it's in bin or sbin. And as a user running the bin/sbin merge, I can tell you based on experience that tab-completion works differently for users vs. superusers with the merge just as it does without it, because again, it's based on ownership and permissions too, not just whether it's in the path (tho it must be that as well). Besides which, users unaccustomed to the CLI (and thus not knowing about tab completion) don't tend to know or care where binaries are anyway, as they prefer menu entries, complete with (graphical) sudo or these days, policy-kit integration. Which is ultimately what distros realized, bin/sbin didn't really matter to the general user any more, thus the bin/sbin merge, as having all installed executables in the same general location was easier to manage and didn't matter to (most) users anyway. But again, gentoo's about choice, and I'd hate to see that choice taken away from gentoo's users anyway, because many of them /do/ actually care, quite a bit in fact, which is why they're on gentoo in the first place. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman