Re: [gentoo-dev] usr merge
My personal opinion: Unless we have a good reason to do otherwise, don't fuck with upstream. On Thu, Apr 7, 2016 at 8:12 PM, Damien Levac wrote: > > > Three points :- > > 1) systemd - not all gentoo users subscribe to this 'philosophy' .. >but > >no, I don't want get drawn into debates of yes/no of systemd .. > > The article start by saying the points are not just for systemd, even > though the latter might find the merge more 'needed'... > > >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 .. so this is a false assumption. > > Agreed, this does not apply to Gentoo. > > >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 sense of the OS .. > > /usr/sbin still exists in a merged usr, so I don't get that point... > > >*hides in his bike-shed, awaiting the flaming torches* > > Don't worry: no troll here. > > -- > Damien Levac > >
Re: [gentoo-dev] usr merge
> Three points :- > 1) systemd - not all gentoo users subscribe to this 'philosophy' .. >but >no, I don't want get drawn into debates of yes/no of systemd .. The article start by saying the points are not just for systemd, even though the latter might find the merge more 'needed'... >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 .. so this is a false assumption. Agreed, this does not apply to Gentoo. >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 sense of the OS .. /usr/sbin still exists in a merged usr, so I don't get that point... >*hides in his bike-shed, awaiting the flaming torches* Don't worry: no troll here. -- Damien Levac
Re: [gentoo-dev] usr merge
On 08/04/16 03:36, Damien Levac wrote: > Anybody who have this kind of misconception about 'usr merge' should > read this: > > https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ > > Signed, > > a user who got scared by this thread and documented myself before > freaking out too much... > >>> Personally I think that merging things into /usr is a major policy >> > decision that is likely to contravene upstream installation >>> locations. I wouldn't do it lightly, if at all. > Three points :- 1) systemd - not all gentoo users subscribe to this 'philosophy' .. but no, I don't want get drawn into debates of yes/no of systemd .. 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 .. so this is a false assumption. 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 sense of the OS .. *hides in his bike-shed, awaiting the flaming torches*
Re: [gentoo-dev] usr merge
Anybody who have this kind of misconception about 'usr merge' should read this: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ Signed, a user who got scared by this thread and documented myself before freaking out too much... >> Personally I think that merging things into /usr is a major policy >> decision that is likely to contravene upstream installation >> locations. I wouldn't do it lightly, if at all. -- Damien Levac
Re: [gentoo-dev] usr merge
On 08/04/16 02:42, William Hubbs wrote: > On Thu, Apr 07, 2016 at 08:39:07PM -0500, William Hubbs wrote: >> On Thu, Apr 07, 2016 at 01:18:01PM -0700, Raymond Jennings wrote: >>> Personally I think that merging things into /usr is a major policy decision >>> that is likely to contravene upstream installation locations. I wouldn't >>> do it lightly, if at all. >> Actually, there are upstreams that already do this, and we are the ones >> that move things around. >> >> Specifically, one example is coreutils. The ebuild installs everything >> in /usr/bin, then we move all of the binaries around. > 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 example. > > William > 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. 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. *puts the paint can down* signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] usr merge
On Thu, Apr 07, 2016 at 08:39:07PM -0500, William Hubbs wrote: > On Thu, Apr 07, 2016 at 01:18:01PM -0700, Raymond Jennings wrote: > > Personally I think that merging things into /usr is a major policy decision > > that is likely to contravene upstream installation locations. I wouldn't > > do it lightly, if at all. > > Actually, there are upstreams that already do this, and we are the ones > that move things around. > > Specifically, one example is coreutils. The ebuild installs everything > in /usr/bin, then we move all of the binaries around. 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 example. William signature.asc Description: Digital signature
Re: [gentoo-dev] usr merge
On Thu, Apr 07, 2016 at 01:18:01PM -0700, Raymond Jennings wrote: > Personally I think that merging things into /usr is a major policy decision > that is likely to contravene upstream installation locations. I wouldn't > do it lightly, if at all. Actually, there are upstreams that already do this, and we are the ones that move things around. Specifically, one example is coreutils. The ebuild installs everything in /usr/bin, then we move all of the binaries around. Also, any time we run gen_usr_ldscript in an ebuild this is going against upstream installation locations. William signature.asc Description: Digital signature
Re: [gentoo-dev] usr merge
Personally I think that merging things into /usr is a major policy decision that is likely to contravene upstream installation locations. I wouldn't do it lightly, if at all. On Thu, Apr 7, 2016 at 11:54 AM, Rich Freeman wrote: > On Thu, Apr 7, 2016 at 2:32 PM, M. J. Everitt wrote: > > In the spirit of hearing arguments for/against .. could someone with the > > appropriate 'fu' throw up a quick survey for those on this ML (and/or > > possibly the g-users?) to indicate a preference for a change to a > > flattened-/usr system? > > > > I did think re: the eudev "debate" that it was really hard to quantify > > the opinion for and against a change, and take it away from the vocal > > people that obviously feel passionately about their cause :) . > > > > By all means do so, but we can probably save the trouble and assume > that 95% of the respondents would prefer things remain as they are, > and probably 80% would suggest that Gentoo should fully support > systems without /usr mounted during early boot. > > Gentoo has become a fairly conservative distro, even more so when > everybody else dropped support for not running systemd. > > I personally think the /usr merge is a cleaner approach (and I'd go a > step further and merge sbin and bin), but it was rightly said that > many of the benefits of a merge only come when you do a lot of other > things as well. Of course, we could go ahead and do those things > later. > > I think the main immediate benefit of a usr merge is that it actually > reduces the risk of shebangs and such pointing to the wrong place (due > to compat links, and there only being one right place in general), and > it greatly consolidates the static stuff on the filesystem. > > -- > Rich > >
Re: [gentoo-dev] usr merge
On Thu, Apr 7, 2016 at 2:32 PM, M. J. Everitt wrote: > In the spirit of hearing arguments for/against .. could someone with the > appropriate 'fu' throw up a quick survey for those on this ML (and/or > possibly the g-users?) to indicate a preference for a change to a > flattened-/usr system? > > I did think re: the eudev "debate" that it was really hard to quantify > the opinion for and against a change, and take it away from the vocal > people that obviously feel passionately about their cause :) . > By all means do so, but we can probably save the trouble and assume that 95% of the respondents would prefer things remain as they are, and probably 80% would suggest that Gentoo should fully support systems without /usr mounted during early boot. Gentoo has become a fairly conservative distro, even more so when everybody else dropped support for not running systemd. I personally think the /usr merge is a cleaner approach (and I'd go a step further and merge sbin and bin), but it was rightly said that many of the benefits of a merge only come when you do a lot of other things as well. Of course, we could go ahead and do those things later. I think the main immediate benefit of a usr merge is that it actually reduces the risk of shebangs and such pointing to the wrong place (due to compat links, and there only being one right place in general), and it greatly consolidates the static stuff on the filesystem. -- Rich
Re: [gentoo-dev] usr merge
On 07/04/16 17:36, Alexis Ballier wrote: > On Thursday, April 7, 2016 6:22:16 PM CEST, Rich Freeman wrote: >> Again, I don't see this as a reason not to make it optional, but I >> suspect that we will find bugs here from time to time which users who >> run with the split /usr will have to report/fix. > > > Considering the advantages of usr-merge are rather specific IMHO but > risks during the migration are high, I think you're optimistic on the > user base of usr-merged systems :) > > Heck, it hasn't happened yet because there hasn't been such a big need > for it. > In the spirit of hearing arguments for/against .. could someone with the appropriate 'fu' throw up a quick survey for those on this ML (and/or possibly the g-users?) to indicate a preference for a change to a flattened-/usr system? I did think re: the eudev "debate" that it was really hard to quantify the opinion for and against a change, and take it away from the vocal people that obviously feel passionately about their cause :) . signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] usr merge
May I suggest first moving everything into /usr one at a time, and for each file moved out of /bin or /sbin or whatever, replace it with a symlink? This will allow the /bin and /sbin directories themselves to atomically be replaced with symlinks later. Doing it all at once will leave a gap. For each file: 1. Install it in the new location 2. Delete the old file and replace it with a symlink On Thu, Apr 7, 2016 at 9:36 AM, Alexis Ballier wrote: > On Thursday, April 7, 2016 6:22:16 PM CEST, Rich Freeman wrote: > >> Again, I don't see this as a reason not to make it optional, but I >> suspect that we will find bugs here from time to time which users who >> run with the split /usr will have to report/fix. >> > > > Considering the advantages of usr-merge are rather specific IMHO but risks > during the migration are high, I think you're optimistic on the user base > of usr-merged systems :) > > Heck, it hasn't happened yet because there hasn't been such a big need for > it. > >
Re: [gentoo-dev] usr merge
On Thursday, April 7, 2016 6:22:16 PM CEST, Rich Freeman wrote: Again, I don't see this as a reason not to make it optional, but I suspect that we will find bugs here from time to time which users who run with the split /usr will have to report/fix. Considering the advantages of usr-merge are rather specific IMHO but risks during the migration are high, I think you're optimistic on the user base of usr-merged systems :) Heck, it hasn't happened yet because there hasn't been such a big need for it.
Re: [gentoo-dev] Re: usr merge
On Thu, Apr 7, 2016 at 11:46 AM, William Hubbs wrote: >> #!/bin/bash will work whether you've done a usr merge or not >> #!/usr/bin/bash will probably only work if you've done the usr merge >> #!/usr/bin/python will work whether you've done a usr merge or not >> #!/bin/python will probably only work if you've done the usr merge > > That's correct, but you shouldn't be using shebangs like the second and > fourth ones now either. The standard shebangs (the first and third > ones) are fully compatible pre and post usr merge. > > If people decide to start using non-standard shebangs like your second > and fourth ones above, that is wrong and should be stopped. > Of course, but how will this be easily prevented? If a package (whether new or a routine update) changes a path somewhere it would work just fine in testing, due to the compatibility symlinks. I can't really think of any straightforward way to detect this in an automated fashion either, at least not 100% reliably. Upstream could introduce these paths without a developer noticing, or a developer might just not notice that netstat and bzip2 and more is in /bin, but lsof and xz and less are in /usr/bin. Since we do not have any policy as to what has to go in either path any of these are subject to change at any time as well. Heck, we struggle just to get people to stop using /etc/init.d/functions.sh. Again, I don't see this as a reason not to make it optional, but I suspect that we will find bugs here from time to time which users who run with the split /usr will have to report/fix. -- Rich
Re: [gentoo-dev] Re: usr merge
On Thu, Apr 07, 2016 at 11:42:01AM -0400, Rich Freeman wrote: > On Thu, Apr 7, 2016 at 11:12 AM, Duncan <1i5t5.dun...@cox.net> wrote: > > William Hubbs posted on Thu, 07 Apr 2016 09:40:49 -0500 as excerpted: > > > >> After the testing period is over, I'm confused about why we should > >> support both layouts. With separate usr without initramfs gone, the usr > >> merge is transparent to end users because of the symbolic links in /, so > >> there should be no reason to keep supporting both layouts once we are > >> satisfied with the migration process. > > > > Because we're Gentoo, and gentooers tend to have rather strong opinions > > on what sort of choices we should be able to make about things like that. > > > > I'm trying to think of whether offering a choice really costs us > anything. The main issue I see here is that the compatibility > symlinks only go one way. > > #!/bin/bash will work whether you've done a usr merge or not > #!/usr/bin/bash will probably only work if you've done the usr merge > #!/usr/bin/python will work whether you've done a usr merge or not > #!/bin/python will probably only work if you've done the usr merge That's correct, but you shouldn't be using shebangs like the second and fourth ones now either. The standard shebangs (the first and third ones) are fully compatible pre and post usr merge. If people decide to start using non-standard shebangs like your second and fourth ones above, that is wrong and should be stopped. William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: usr merge
On Thu, Apr 7, 2016 at 11:12 AM, Duncan <1i5t5.dun...@cox.net> wrote: > William Hubbs posted on Thu, 07 Apr 2016 09:40:49 -0500 as excerpted: > >> After the testing period is over, I'm confused about why we should >> support both layouts. With separate usr without initramfs gone, the usr >> merge is transparent to end users because of the symbolic links in /, so >> there should be no reason to keep supporting both layouts once we are >> satisfied with the migration process. > > Because we're Gentoo, and gentooers tend to have rather strong opinions > on what sort of choices we should be able to make about things like that. > I'm trying to think of whether offering a choice really costs us anything. The main issue I see here is that the compatibility symlinks only go one way. #!/bin/bash will work whether you've done a usr merge or not #!/usr/bin/bash will probably only work if you've done the usr merge #!/usr/bin/python will work whether you've done a usr merge or not #!/bin/python will probably only work if you've done the usr merge It seems like a bit of a challenge to try to make sure that all your links are to wherever the original package tries to install files when on the system you are developing/testing on everything is in one place. We could of course require that maintainers accept patches to fix these kinds of broken links if they're offered, but users would be more likely to run into temporary breakage if they didn't use the merge unless we can come up with a way to offer compatibility in both directions. Unless there is a bigger problem lurking it probably still should be up to the user. -- Rich
[gentoo-dev] Re: usr merge
William Hubbs posted on Thu, 07 Apr 2016 09:40:49 -0500 as excerpted: > After the testing period is over, I'm confused about why we should > support both layouts. With separate usr without initramfs gone, the usr > merge is transparent to end users because of the symbolic links in /, so > there should be no reason to keep supporting both layouts once we are > satisfied with the migration process. Because we're Gentoo, and gentooers tend to have rather strong opinions on what sort of choices we should be able to make about things like that. Honestly, that's going to look to a lot of people like another of the systemd/RedHat alliance overreaches and they're not going to go for it, simple as that. People are likely to feel strongly enough about it that we'll be risking triggering a distro split. The ability to make that sort of choice is /why/ they are on gentoo. So by all means, present it as an option, document it in the handbooks, and even make it the default (and we all know how strongly people feel about even changing a default after the eudev debate), but I don't think it's a fight worth having to take away the other choices. At least not now. Maybe in five or ten years, after another generation of devs has come and gone, if the new one isn't interested in supporting the alternative any longer. (Again, I say this as one who has already done the merge here, if in reverse, and who fully intends to setup new systems the same way as well.) -- 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
[gentoo-dev] Last rites: media-libs/libmnote
# Michael Palimaka (07 Apr 2016) # Obsolete. Merged into media-libs/libexif. # Masked for removal in 30 days. media-libs/libmnote
Re: [gentoo-dev] usr merge
On Thu, Apr 07, 2016 at 11:12:13AM +0200, Alexis Ballier wrote:
> On Wednesday, April 6, 2016 11:36:09 PM CEST, Richard Yao wrote:
> > As for those benefits, they do little for {/usr,}/sbin vs
> > {/usr,}/bin, which is where the incompatibilities tend to live.
> > I encountered one of these in powertop the other day (patch
> > pending). The benefits of being able to access things from both
> > places are somewhat exaggerated given that compatibility among
> > systems has long required searching $PATH and likely always
> > will.
>
> PATH is a shell thing; some libc functions like execvp duplicate this
> functionality but that's all; you dont have PATH in shebangs nor in execv.
>
> >> Note, we are not
> >> talking about squashing /usr out of the equasion, but merging /bin,
> >> /sbin and /lib* into their counterparts in /usr and creating symlinks in
> >> the root directory pointing to the counterparts in /usr.
> >
> > While one guy did the reverse (and the reverse ought to be okay
> > for those that want to do that), no one appears to think that
> > adopting the reverse is what is being suggested. Having this
> > sort of clarity on whether forcing this on everyone via
> > baselayout update, just providing the option for those who want
> > it or some combination of the two (e.g. a long transition period
> > in which both are supported) is being discussed would be nice
> > though. This is not a Boolean decision.
>
> I've been under the impression since the beginning of the thread that it is
> what is being proposed: make it possible but support both. We can't force
> usr-merge without battle testing the migration process anyway, which means
> there needs to be such a long transition period.
I do agree that we need a testing period to iron out the migration
process. Like I said, I'm not quite comfortable even with running it
here because I don't know if it will break my system, and once you do
the migration, the only way to undo it is to wipe and re-install. I have
thought about a way to roll back, but I don't see that as very feesable,
so once you migrate to a /usr merged setup, there is no way to undo it.
Also, the usr merge affects linux only; we aren't talking about
messing with *bsd.
After the testing period is over, I'm confused about why we should
support both layouts. With separate usr without initramfs gone, the usr
merge is transparent to end users because of the symbolic links in /, so
there should be no reason to keep supporting both layouts once we are
satisfied with the migration process.
William
signature.asc
Description: Digital signature
Re: [gentoo-dev] usr merge
On Wed, Apr 6, 2016 at 4:04 PM, Richard Yao wrote: > On Apr 6, 2016, at 3:42 AM, Alexis Ballier wrote: >> On Wednesday, April 6, 2016 6:15:58 AM CEST, Richard Yao wrote: >>> >>> Here are the violations: >>> >>> http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#binEssentialUserCommandBinaries >>> >>> http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#sbinSystemBinaries >>> >>> http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#libEssentialSharedLibrariesAndKern >> >> well, those are not violations: fhs mandates a certain set of >> binaries in those paths; this is still the case with a usr-merged >> system. >> >> i thought the symlinks would be a problem, but fhs states: >>> >>> The following directories, or symbolic links to directories, are required >>> in /. >> >> so, really, i dont see any violation there > > Nice. They added that to fix it. More likely you missed it in the past because 2004's FHS 2.3 has "The following directories, or symbolic links to directories, are required in /." in http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#REQUIREMENTS
Re: [gentoo-dev] usr merge
On Wednesday, April 6, 2016 11:36:09 PM CEST, Richard Yao wrote:
As for those benefits, they do little for {/usr,}/sbin vs
{/usr,}/bin, which is where the incompatibilities tend to live.
I encountered one of these in powertop the other day (patch
pending). The benefits of being able to access things from both
places are somewhat exaggerated given that compatibility among
systems has long required searching $PATH and likely always
will.
PATH is a shell thing; some libc functions like execvp duplicate this
functionality but that's all; you dont have PATH in shebangs nor in execv.
Note, we are not
talking about squashing /usr out of the equasion, but merging /bin,
/sbin and /lib* into their counterparts in /usr and creating symlinks in
the root directory pointing to the counterparts in /usr.
While one guy did the reverse (and the reverse ought to be okay
for those that want to do that), no one appears to think that
adopting the reverse is what is being suggested. Having this
sort of clarity on whether forcing this on everyone via
baselayout update, just providing the option for those who want
it or some combination of the two (e.g. a long transition period
in which both are supported) is being discussed would be nice
though. This is not a Boolean decision.
I've been under the impression since the beginning of the thread that it is
what is being proposed: make it possible but support both. We can't force
usr-merge without battle testing the migration process anyway, which means
there needs to be such a long transition period.
Alexis.
Re: [gentoo-dev] usr merge
On Wednesday, April 6, 2016 5:52:52 PM CEST, Richard Yao wrote: The original purpose of the /usr merge in Solaris was to make managing updates easier. Redhat realized that and copied it. Copying it too without doing the enabling work necessary for a rolling distribution would be setting a trap for users who would think that they can manage deployments of Gentoo like they can manage deployments Solaris and/or RHEL. You're tying the whole thing too much to solaris/rh ways. The benefits for us are far less than for them and managing updates via everything in /usr is certainly out of scope of the current proposal.
