Re: [gentoo-dev] usr merge

2016-04-08 Thread waltdnes
On Fri, Apr 08, 2016 at 11:59:09PM -0400, Damien Levac wrote > > > Seriously... how many people run Bluetooth keyboards on Gentoo > > anyways? > > That you ask such a question is concerning to me. Are we > discriminating against normal desktop users now? Here's the item that really bugs

[gentoo-dev] Re: usr merge

2016-04-08 Thread Duncan
Rich Freeman posted on Fri, 08 Apr 2016 06:36:48 -0400 as excerpted: > Really though the main point of merging these paths into /usr is to get > all the static content of a distro into a single path, which can then be > maintained as a read-only filesystem, mounted across multiple systems, >

Re: [gentoo-dev] usr merge

2016-04-08 Thread Anthony G. Basile
On 4/8/16 11:54 PM, Damien Levac wrote: >> I personally think sharing /usr over a network and deploying it to >> multiple machines could be a recipe for disaster. > > Uh... it is a nice opinion, but when you are managing 1000+ machines, > scripting is not cutting it anymore. Obviously we are

Re: [gentoo-dev] usr merge

2016-04-08 Thread Anthony G. Basile
On 4/8/16 11:03 PM, Rich Freeman wrote: > On Fri, Apr 8, 2016 at 9:51 PM, Anthony G. Basile wrote: >> >> Alternatively, this may introduce problems. So it seems like we're >> fixing something that isn't broken. >> > > What problems are you anticipating, especially in light

Re: [gentoo-dev] usr merge

2016-04-08 Thread Damien Levac
> Seriously... how many people run Bluetooth keyboards on Gentoo >anyways? That you ask such a question is concerning to me. Are we discriminating against normal desktop users now? -- Damien Levac

Re: [gentoo-dev] usr merge

2016-04-08 Thread Damien Levac
>I personally think sharing /usr over a network and deploying it to >multiple machines could be a recipe for disaster. Uh... it is a nice opinion, but when you are managing 1000+ machines, scripting is not cutting it anymore. Obviously we are network distributing it. Not that we aren't already

Re: [gentoo-dev] usr merge

2016-04-08 Thread Rich Freeman
On Fri, Apr 8, 2016 at 9:51 PM, Anthony G. Basile wrote: > > Alternatively, this may introduce problems. So it seems like we're > fixing something that isn't broken. > What problems are you anticipating, especially in light of the fact that many distros actually do it this

Re: [gentoo-dev] usr merge

2016-04-08 Thread Anthony G. Basile
On 4/8/16 9:36 PM, William Hubbs wrote: > On Fri, Apr 08, 2016 at 09:11:48PM -0400, Anthony G. Basile wrote: >> On 4/8/16 8:42 PM, William Hubbs wrote: >> >>> >>> It is true that we offer a high degree of choice to users, but one of >>> those choices is not which paths to install binaries and

Re: [gentoo-dev] usr merge

2016-04-08 Thread William Hubbs
On Fri, Apr 08, 2016 at 09:11:48PM -0400, Anthony G. Basile wrote: > On 4/8/16 8:42 PM, William Hubbs wrote: > > > > > It is true that we offer a high degree of choice to users, but one of > > those choices is not which paths to install binaries and libraries > > into. > > I thought vapier was

Re: [gentoo-dev] usr merge

2016-04-08 Thread Austin English
On 04/08/2016 08:18 PM, waltd...@waltdnes.org wrote: > On Fri, Apr 08, 2016 at 04:30:04PM -0400, Rich Freeman wrote > >> Half the reason we don't officially support running without /usr >> mounted during early boot is that if we actually put everything in / >> that could conceivably be needed

Re: [gentoo-dev] usr merge

2016-04-08 Thread waltdnes
On Fri, Apr 08, 2016 at 04:30:04PM -0400, Rich Freeman wrote > Half the reason we don't officially support running without /usr > mounted during early boot is that if we actually put everything in / > that could conceivably be needed during early boot we'd end up with > everything there.

Re: [gentoo-dev] usr merge

2016-04-08 Thread waltdnes
On Fri, Apr 08, 2016 at 04:18:58PM -0400, Joseph Booker wrote > > From my own experience, it is useful to run "ifconfig" or "mount" > as a regular user, same as the gimp or firefox commands. Given that > all the commands you listed are in /usr/bin or /bin, I think I'm > not the only one. The

Re: [gentoo-dev] usr merge

2016-04-08 Thread Anthony G. Basile
On 4/8/16 8:42 PM, William Hubbs wrote: > > It is true that we offer a high degree of choice to users, but one of > those choices is not which paths to install binaries and libraries > into. I thought vapier was introducing a switch USE=usr-sep which allowed us to keep an unmerged /usr, or are

Re: [gentoo-dev] usr merge

2016-04-08 Thread William Hubbs
On Fri, Apr 08, 2016 at 03:20:24PM -0700, Daniel Campbell wrote: > Based on what I've read here in the thread, merging /bin and /sbin > into /usr/{sbin,bin} is a matter of convenience by putting most of the > static parts of a running system into a single path. As mentioned by > some people,

Re: [gentoo-dev] usr merge

2016-04-08 Thread Daniel Campbell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/08/2016 04:31 AM, Anthony G. Basile wrote: > On 4/8/16 6:14 AM, Rich Freeman wrote: >> On Thu, Apr 7, 2016 at 9:42 PM, William Hubbs >> wrote: >>> >>> There was a bypo here. "the ebuild" should be upstream. The >>>

Re: [gentoo-dev] [PATCH v1 1/3] general-concepts/herds-and-projects: update per GLEP 67 #572144 #549490

2016-04-08 Thread Andreas K. Huettel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Monday 04 April 2016 06:57:51 NP-Hardass wrote: > On 04/04/2016 12:34 AM, Göktürk Yüksek wrote: > > +sufficient for adding or removing a developer. Note that > > different +projects have different requirements and procedures for > > recruiting

Re: [gentoo-dev] usr merge

2016-04-08 Thread Rich Freeman
On Fri, Apr 8, 2016 at 4:18 PM, Joseph Booker wrote: > The difference between "system software" and "regular applications" isn't > clear-cut. > This. Half the reason we don't officially support running without /usr mounted during early boot is that if we actually put

Re: [gentoo-dev] usr merge

2016-04-08 Thread waltdnes
On Fri, Apr 08, 2016 at 09:20:19AM -0500, William Hubbs wrote > > Here is more info about the split and why it exists. It turns out it hs > nothing to do with system admininistration or permissions. > > http://lists.busybox.net/pipermail/busybox/2010-December/074114.html >

Re: [gentoo-dev] usr merge

2016-04-08 Thread Rich Freeman
On Fri, Apr 8, 2016 at 11:14 AM, M. J. Everitt wrote: > Being serious though, and playing Devil's Advocate of course, assuming > you have no use for a desktop manager, etc, hence no need for dbus or > it's 'friends' and policykit or it's pals, and you're not a "systemd > fan"

Re: [gentoo-dev] usr merge

2016-04-08 Thread Alexis Ballier
On Friday, April 8, 2016 5:14:42 PM CEST, M. J. Everitt wrote: On 08/04/16 16:02, Rich Freeman wrote: The only mandatory component in a linux system, by definition, is the Linux kernel. A linux system could consist of nothing but a kernel with init=/usr/local/bin/hello-world. Most traditional

Re: [gentoo-dev] usr merge

2016-04-08 Thread M. J. Everitt
On 08/04/16 16:02, Rich Freeman wrote: > > The only mandatory component in a linux system, by definition, is the > Linux kernel. > > A linux system could consist of nothing but a kernel with > init=/usr/local/bin/hello-world. > > Most traditional linux distros are going to run policykit though.

Re: [gentoo-dev] usr merge

2016-04-08 Thread M. J. Everitt
On 08/04/16 16:02, Rich Freeman wrote: > On Fri, Apr 8, 2016 at 10:33 AM, M. J. Everitt wrote: >> I'll come back to the links a bit later, but is policykit and its >> predecessor/derivatives now a mandatory part of a linux system? >> > The only mandatory component in a linux

Re: [gentoo-dev] usr merge

2016-04-08 Thread Rich Freeman
On Fri, Apr 8, 2016 at 10:33 AM, M. J. Everitt wrote: > I'll come back to the links a bit later, but is policykit and its > predecessor/derivatives now a mandatory part of a linux system? > The only mandatory component in a linux system, by definition, is the Linux kernel.

Re: [gentoo-dev] pokit (was: usr merge)

2016-04-08 Thread Ian Stakenvicius
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/04/16 10:33 AM, M. J. Everitt wrote: > I'll come back to the links a bit later, but is policykit and > its predecessor/derivatives now a mandatory part of a linux > system? > > Possibly crossing posts here, so apologies in advance .. ! :] >

Re: [gentoo-dev] usr merge

2016-04-08 Thread M. J. Everitt
On 08/04/16 15:20, William Hubbs wrote: > On Fri, Apr 08, 2016 at 03:44:06AM +0100, M. J. Everitt wrote: >> 3) I still believe there is merit in distinguishing between binaries >> that can/should be run as root, and those that can/should not. Those >> that run as root 100% of the time, or use VMs,

Re: [gentoo-dev] usr merge

2016-04-08 Thread William Hubbs
On Fri, Apr 08, 2016 at 03:44:06AM +0100, M. J. Everitt wrote: > 3) I still believe there is merit in distinguishing between binaries > that can/should be run as root, and those that can/should not. Those > that run as root 100% of the time, or use VMs, don't really 'use' linux > in the original

Re: [gentoo-dev] usr merge

2016-04-08 Thread Rich Freeman
On Fri, Apr 8, 2016 at 7:54 AM, Anthony G. Basile wrote: > > As I'm getting into this thread, I'm looking at debian, fedora and I'll > add openSUSE. I just don't get why a usr merge is as good as that > fedora page says. > Keep in mind Fedora's purposes here: 1. It is a

Re: [gentoo-dev] usr merge

2016-04-08 Thread Anthony G. Basile
On 4/8/16 7:41 AM, James Le Cuirot wrote: > On Fri, 8 Apr 2016 07:31:03 -0400 > "Anthony G. Basile" wrote: > >> On 4/8/16 6:14 AM, Rich Freeman wrote: >>> On Thu, Apr 7, 2016 at 9:42 PM, William Hubbs >>> wrote: There was a bypo here. "the

Re: [gentoo-dev] usr merge

2016-04-08 Thread Rich Freeman
On Fri, Apr 8, 2016 at 7:41 AM, James Le Cuirot wrote: > On Fri, 8 Apr 2016 07:31:03 -0400 > "Anthony G. Basile" wrote: >> >> @anyone, can you list the reasons we're doing this (I'm sure there's >> more than one). If systemd if one of them, then I'm

Re: [gentoo-dev] usr merge

2016-04-08 Thread James Le Cuirot
On Fri, 8 Apr 2016 07:31:03 -0400 "Anthony G. Basile" wrote: > On 4/8/16 6:14 AM, Rich Freeman wrote: > > On Thu, Apr 7, 2016 at 9:42 PM, William Hubbs > > wrote: > >> > >> There was a bypo here. "the ebuild" should be upstream. The default > >>

Re: [gentoo-portage-dev] [PATCH] emerge: add --search-fuzzy and --search-fuzzy-cutoff options (bug 65566)

2016-04-08 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/04/16 08:21, Zac Medico wrote: > Reverse? You want it to measure dissimilarity? Not sure what you > mean. Sorry, I meant reverse the *docs* to mean "find things that are at least 50% similar" rather than "cut off things that aren't above the

Re: [gentoo-dev] usr merge

2016-04-08 Thread Anthony G. Basile
On 4/8/16 6:14 AM, Rich Freeman wrote: > On Thu, Apr 7, 2016 at 9:42 PM, William Hubbs wrote: >> >> There was a bypo here. "the ebuild" should be upstream. The default >> installation location of all coreutils binaries is /usr/bin, then we >> move everything around in the

Re: [gentoo-dev] usr merge

2016-04-08 Thread Rich Freeman
On Thu, Apr 7, 2016 at 10:44 PM, M. J. Everitt wrote: > 2) "Today, a separate /usr partition already must be mounted by the > initramfs during early boot, thus making the justification for a > split-off moot." - no, not all gentoo users have an initramfs and > need/want one

Re: [gentoo-dev] usr merge

2016-04-08 Thread Rich Freeman
On Thu, Apr 7, 2016 at 9:42 PM, William Hubbs wrote: > > There was a bypo here. "the ebuild" should be upstream. 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

[gentoo-dev] Re: usr merge

2016-04-08 Thread Duncan
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

Re: [gentoo-portage-dev] [PATCH] egencache --update-changelogs: fix timestamp assumptions (bug 579292)

2016-04-08 Thread Zac Medico
On 04/07/2016 11:51 PM, Brian Dolbec wrote: > the above looks good, but what about: > > > [19:01] just use --first-parent > [19:01] also take into account merge commits > [19:03] git really complicates ChangeLog generation in general > [19:03]

Re: [gentoo-portage-dev] [PATCH] egencache --update-changelogs: fix timestamp assumptions (bug 579292)

2016-04-08 Thread Brian Dolbec
On Thu, 7 Apr 2016 22:46:25 -0700 Zac Medico wrote: > Since commit times are not necessarily ordered, synchronize the > ChangeLog mtime with the last commit time, and use exact comparison > to detect changes. > > X-Gentoo-bug: 579292 > X-Gentoo-bug-url: