Re: [gentoo-dev] usr merge

[J. Roeleveld]

On Monday, April 11, 2016 01:10:15 AM Raymond Jennings wrote:
> Please don't do this.  I want my system left alone.

Please don't top-post, I want to have a logical flow of the text.


> On Sun, Apr 10, 2016 at 11:41 PM, J. Roeleveld  wrote:
> > On Sunday, April 10, 2016 10:04:42 AM James Le Cuirot wrote:
> > > On Sun, 10 Apr 2016 02:09:35 +0200
> > > 
> > > "J. Roeleveld"  wrote:
> > > > I actually write my own initramfs because neither dracut not
> > > > genkernel end up with a convenient boot system.
> > > > 
> > > > I have 2 disks, both encrypted.
> > > > I prefer only to enter the decryption password once. Both Dracut and
> > > > Genkernel insist on asking for the password/key for every single disk.
> > > 
> > > Dracut on RHEL actually handles this out of the box. Might be worth
> > > finding out how.
> > 
> > Might have even been fixed in a more recent version of Dracut.
> > I just have passed the point where I am interested in it enough to try it.
> > The
> > initramfs I use gets embedded into the kernel and doesn't need any kernel
> > parameters to work.
> > 
> > It does what it needs to do with minimal work. The simplicity should also
> > make
> > it faster than the scripts generated by either Dracut or genkernel. (As
> > they
> > need to parse the kernel cmdline and try to figure out static details on
> > the
> > fly)
> > 
> > --
> > Joost

Please d

Re: [gentoo-dev] usr merge

[Raymond Jennings]

Please don't do this.  I want my system left alone.



On Sun, Apr 10, 2016 at 11:41 PM, J. Roeleveld  wrote:

> On Sunday, April 10, 2016 10:04:42 AM James Le Cuirot wrote:
> > On Sun, 10 Apr 2016 02:09:35 +0200
> >
> > "J. Roeleveld"  wrote:
> > > I actually write my own initramfs because neither dracut not
> > > genkernel end up with a convenient boot system.
> > >
> > > I have 2 disks, both encrypted.
> > > I prefer only to enter the decryption password once. Both Dracut and
> > > Genkernel insist on asking for the password/key for every single disk.
> >
> > Dracut on RHEL actually handles this out of the box. Might be worth
> > finding out how.
>
> Might have even been fixed in a more recent version of Dracut.
> I just have passed the point where I am interested in it enough to try it.
> The
> initramfs I use gets embedded into the kernel and doesn't need any kernel
> parameters to work.
>
> It does what it needs to do with minimal work. The simplicity should also
> make
> it faster than the scripts generated by either Dracut or genkernel. (As
> they
> need to parse the kernel cmdline and try to figure out static details on
> the
> fly)
>
> --
> Joost

Re: [gentoo-dev] usr merge

[J. Roeleveld]

On Sunday, April 10, 2016 10:04:42 AM James Le Cuirot wrote:
> On Sun, 10 Apr 2016 02:09:35 +0200
> 
> "J. Roeleveld"  wrote:
> > I actually write my own initramfs because neither dracut not
> > genkernel end up with a convenient boot system.
> > 
> > I have 2 disks, both encrypted.
> > I prefer only to enter the decryption password once. Both Dracut and
> > Genkernel insist on asking for the password/key for every single disk.
> 
> Dracut on RHEL actually handles this out of the box. Might be worth
> finding out how.

Might have even been fixed in a more recent version of Dracut.
I just have passed the point where I am interested in it enough to try it. The 
initramfs I use gets embedded into the kernel and doesn't need any kernel 
parameters to work.

It does what it needs to do with minimal work. The simplicity should also make 
it faster than the scripts generated by either Dracut or genkernel. (As they 
need to parse the kernel cmdline and try to figure out static details on the 
fly)

--
Joost

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] usr merge

[Joshua Kinard]

On 04/10/2016 08:14, Rich Freeman wrote:
> On Sun, Apr 10, 2016 at 7:55 AM, Joshua Kinard  wrote:
>>
>> Create like, a table on the Wiki or some kind of metadata property 
>> per-package
>> that can contain a boolean or tri-state flag indicating whether it works or
>> doesn't work (or kinda works) on split-usr.  Or a tracker on Bugzie.  
>> Something.
>>
> 
> I'm sure there will be a tracker for packages that don't work on a
> merged /usr.  (We are already on a split /usr.)
> 
> Honestly, I'm still not quite sure why we're even having this
> discussion.  I don't think anybody actually intends to make any
> changes at all.  If they do, they should issue some kind of plan and
> indicate what they're looking for from everybody else.

Agreed.  A plan is most definitely needed if we ever choose to pursue a policy
of only supporting non-split-/usr installs, especially if we want to handle
cases like mine where we try to make migration of existing installs possible or
not.


[snip]

> It seems to me that we're just having a general discussion about the
> pros/cons of a /usr merge.  That is nice, but people are getting
> worked up because they think that somehow whoever "loses" this
> "discussion" will get something shoved down their throats or won't be
> able to have something nice.

"General discussion" -- hah!  Maybe it's the way Thunderbird is displaying it,
but I have five distinct, top-level threads in my gentoo-dev folder for this
discussion.  I think we left "general" back there after we broke through the
plaid barrier.

That said, I don't really think there are any pros or cons of split or merged.
 Largely, what's being discussed is the after-effects of what once was a common
approach to filesystem layout.  Myself, I only went the split-usr route because
of habit, itself which started because when I set up my first Gentoo system.  I
studied both the then-Gentoo Security and Debian Security manuals, which
indicated a split-/usr layout had certain advantages in that you could limit
capabilities via mount options.  Mainly, /usr didn't need devices, so "nodev"
was common there.  Along with /var having "noexec" and "nodev".

I've pretty much stuck to that layout approach since then out of habit.
Certainly, I've got a few VMs where I have just /, /boot, and /tmp as my only
partitions, and there's no real noticeable difference except what's in 
/etc/fstab.

---

I think where the problem ultimately arises is a subtle conflict between
filesystem semantics and system-design philosophy against the Linux kernel's
device architecture and management.  It's long regarded that /bin and /sbin
contain system-level binaries, and /usr/bin and /usr/sbin being for almost
everything else.  A.k.a., a two-level binary installation hierarchy (and the
BSD's extend this with a third level under /usr/local).

>From the kernel angle, you have a monolithic kernel design where device drivers
run in kernel space most of the time.  This worked okay with traditional,
static devices that didn't change a whole lot and whose resources could be
determined at boot-time, before userspace is brought up.  But once the Linux
ecosystem needed devices that can come online from userspace or need their
resource determination to be dynamic (e.g., for hotplugging), we went to the
approach that the kernel needs to get out of managing devices altogether, and
thus came up with udev for device management from userspace.

Since udev is supposed to run from userspace, but kinda needs to interface with
the kernel a lot, the split between what's system-specific and what's not
clashes with the two-level file system layout.  This wasn't anything new...this
conflict has existed elsewhere for a long time (namely in X11), but it came to
a head when udev maintainers (and later, systemd maintainers) questioned the
approach, and largely decided it wasn't worth it, and a merged filesystem, with
/usr not separate, was simpler and more elegant.

---

But really, does it matter where the binaries all live?  It's just a design
decision.  Every OS had a different approach, such as NetWare running virtually
everything out of SYS:SYSTEM, and Windows out of C:\WINDOWS.  Heck, for the
longest time, you could *not* install Windows on anything other than the first
partition of the first drive, because software literally hardcoded filespec
strings as "C:\WINDOWS\...".  And even why C:, the third letter of the
alphabet, for the first fixed disk?  Because A: and B: were reserved for
systems that needed two floppy drives.  Yay MS-DOS!

If it were possible to give every binary and file out there a unique name, you
wouldn't even need directories.  You could have a totally-flat namespace with
all files of any kind under /, and let security models handle who sees/accesses
what.  But in that setup, would you even need "/"?


> Almost every big change that has become popular in Gentoo just started
> out as another alternative, and support grew organically.  I don't
> 

Re: [gentoo-dev] usr merge

[Robin H. Johnson]

On Fri, Apr 08, 2016 at 09:18:37PM -0400, 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 during early boot we'd end up with
> > everything there.  Bluetooth keyboards is a common example.  The
> > console should work during early boot, right?
>   Seriously... how many people run Bluetooth keyboards on Gentoo anyways?
I had a BT keyboard on my last Gentoo-based mediacentre box so that I
could sit on the couch and still use it...

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead, Foundation Trustee
E-Mail : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] usr merge

[Anthony G. Basile]

On 4/10/16 8:14 AM, Rich Freeman wrote:
> 
> Honestly, I'm still not quite sure why we're even having this
> discussion.  I don't think anybody actually intends to make any
> changes at all.  If they do, they should issue some kind of plan and
> indicate what they're looking for from everybody else.
> 

Because William started this thread,

http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg73010.html

and because the passive voice in the sentence "I thought that since the
usr merge is coming up again" begs the question:  Who is bringing it up
and why?  So ... questioning minds want to know.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] usr merge

[Anthony G. Basile]

On 4/10/16 7:55 AM, Joshua Kinard wrote:
> On 04/04/2016 21:19, William Hubbs wrote:
>> All,
>>
>> I thought that since the usr merge is coming up again, and since I lost
>> track of the message where it was brought up, I would open a
>> new thread to discuss it.

Why is this coming up?  What problem(s) are we trying to solve with the
usr merge.  I'm still not clear on this.

@William can you please answer this?

>>
>> When it came up before, some were saying that the /usr merge violates
>> the fhs. I don't remember the specifics of what the claim was at the
>> time, (I'm sure someone will point it out if it is still a concern).
>>
>> I don't think creating usr merged stages would be that difficult. I
>> think it would just be a matter of creating a new version of baselayout
>> that puts these symlinks in place:

If you give me a prototype baselayout (or I can write one myself but I'd
rather see what you have in mind) I could test some catalyst runs and
see.  I could put these on the /experimental for others to look at.

>>
>> /bin->usr/bin
>> /lib->usr/lib
>> /lib32->usr/lib32
>> /lib64->usr/lib64
>> /sbin->usr/bin
>> /usr/sbin->bin
>>
>> Once that is in place in a new baselayout, I think portage's colission
>> detection would be able to catch files that had the same names and were
>> originally in different paths when building the new stages.
>>
>> I put some thought also in how to nigrate live systems, and I'm not sure
>> what the best way to do that is. I wrote a script, which would do it in
>> theory, but I haven't tested because I only have one system and if
>> it breaks it the only way back would be to reinstall.
>>
>> The script is attached.
>>
>>
>> Thoughts on any of this?
>>
>> William
> 
> I looked at Thunderbird, at my folder labeled "gentoo-dev", and it had "666"
> unread messages.  I should've done the smart thing and closed my mail program.
>  But n, I had to look inside the folder.  I am now regretting this 
> decision.

Did you round off to the nearest evil?

> 
> *sigh*, I can see the thread has gone clongie 'round the blonger, so all I'll
> have to say is we should still try to maintain the choice for users.  But, in
> order to evaluate what amount of effort is needed to maintain that choice, we
> need to know what packages break on such a setup, what the level of effort
> needed to fix them is, and do those fixes impact the non-split crowd.

I tested and it will affect systems using RBAC.  So if we force people
to migrate, then users of hardened-sources using RBAC will have to
update their policy file.

To be clear, I'm not against moving forwards with this, but we can't
these people hanging because hardened-sources+RBAC is one reason people
in the industry consider gentoo at all.  I'm willing to help with
backwards compat.

> 
> Create like, a table on the Wiki or some kind of metadata property per-package
> that can contain a boolean or tri-state flag indicating whether it works or
> doesn't work (or kinda works) on split-usr.  Or a tracker on Bugzie.  
> Something.

+1

> 
> Once we know this, then we can work out what's the minimum system that can be
> successfully run on split-usr.  Then, knowing *that*, we can see if that 
> system
> can be supported by our @system target or some minimal subset of @world.  As
> new package versions come out of upstream, we update this metadata with 
> changes
> to the split-usr status, and this then provides a history of the more or less
> amount of difficulty needed to maintain support for split-usr, and *then*, we
> can make an objective decision to continue supporting or not supporting the
> capability.
> 
> As for me, I am flat out ruling out a full-reinstall of all my systems.  I 
> have
> fixed disk partition layouts on all of them that cannot be re-arranged unless 
> I
> tar up each filesystem and temporarily move it off, then rebuild the MD-RAID
> and reformat the filesystems.  I am simply not going to do that on my many SGI
> systems, and whatever facet of upstream, whether it's some core GNU package or
> RH itself, can go pound sand for all I care.  I'll go back to a static /dev 
> and
> I'll manually mknod any missing devices if I have to.

Not just you, but many sys admins out there in the real world are in
similar situation.  Again we can move forward on this but not without
backwards compat planning.

> 
> You know it's getting ridiculous when you can maintain a Windows/NTFS 
> partition
> layout easier than a Linux one.
> 

Has it come to that?


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sun, Apr 10, 2016 at 7:55 AM, Joshua Kinard  wrote:
>
> Create like, a table on the Wiki or some kind of metadata property per-package
> that can contain a boolean or tri-state flag indicating whether it works or
> doesn't work (or kinda works) on split-usr.  Or a tracker on Bugzie.  
> Something.
>

I'm sure there will be a tracker for packages that don't work on a
merged /usr.  (We are already on a split /usr.)

Honestly, I'm still not quite sure why we're even having this
discussion.  I don't think anybody actually intends to make any
changes at all.  If they do, they should issue some kind of plan and
indicate what they're looking for from everybody else.

Such as: "Hello, I help maintain baselayout and I intend to change
/(s)lib and /(s)bin and /usr/sbin into symlinks to /usr/bin and move
all the files into those directories there.  To test this out now
please do xyz, and report any bugs against tracker #123456."

Or: "Hello, I help maintain baselayout and I just introduced a new USE
flag which does ...  I think it is something you should try out.  Bugs
can be reported at..."

Or: "Hello, I think the baselayout maintainers are idiots and I just
introduced librelayout which does ...  You should definitely switch
because only losers run with a split /usr.  Bugs can be reported at...
Oh, and my fancy librelayout doesn't need gen_usr_ldscript so I
select_one_of('won't lift a finger to keep it working', 'will just
laugh at the folks who are wasting their time keeping it working')."

It seems to me that we're just having a general discussion about the
pros/cons of a /usr merge.  That is nice, but people are getting
worked up because they think that somehow whoever "loses" this
"discussion" will get something shoved down their throats or won't be
able to have something nice.

Almost every big change that has become popular in Gentoo just started
out as another alternative, and support grew organically.  I don't
really see the need to reach some kind of consensus here.  I'd love to
have an option of a /usr merge and a migration path.  I'd love to see
it as the default, but that is a different discussion, and if it is
optional then it is also a less contentious discussion whichever way
it goes.

-- 
Rich

Re: [gentoo-dev] usr merge

[Joshua Kinard]

On 04/04/2016 21:19, William Hubbs wrote:
> All,
> 
> I thought that since the usr merge is coming up again, and since I lost
> track of the message where it was brought up, I would open a
> new thread to discuss it.
> 
> When it came up before, some were saying that the /usr merge violates
> the fhs. I don't remember the specifics of what the claim was at the
> time, (I'm sure someone will point it out if it is still a concern).
> 
> I don't think creating usr merged stages would be that difficult. I
> think it would just be a matter of creating a new version of baselayout
> that puts these symlinks in place:
> 
> /bin->usr/bin
> /lib->usr/lib
> /lib32->usr/lib32
> /lib64->usr/lib64
> /sbin->usr/bin
> /usr/sbin->bin
> 
> Once that is in place in a new baselayout, I think portage's colission
> detection would be able to catch files that had the same names and were
> originally in different paths when building the new stages.
> 
> I put some thought also in how to nigrate live systems, and I'm not sure
> what the best way to do that is. I wrote a script, which would do it in
> theory, but I haven't tested because I only have one system and if
> it breaks it the only way back would be to reinstall.
> 
> The script is attached.
> 
> 
> Thoughts on any of this?
> 
> William

I looked at Thunderbird, at my folder labeled "gentoo-dev", and it had "666"
unread messages.  I should've done the smart thing and closed my mail program.
 But n, I had to look inside the folder.  I am now regretting this decision.

*sigh*, I can see the thread has gone clongie 'round the blonger, so all I'll
have to say is we should still try to maintain the choice for users.  But, in
order to evaluate what amount of effort is needed to maintain that choice, we
need to know what packages break on such a setup, what the level of effort
needed to fix them is, and do those fixes impact the non-split crowd.

Create like, a table on the Wiki or some kind of metadata property per-package
that can contain a boolean or tri-state flag indicating whether it works or
doesn't work (or kinda works) on split-usr.  Or a tracker on Bugzie.  Something.

Once we know this, then we can work out what's the minimum system that can be
successfully run on split-usr.  Then, knowing *that*, we can see if that system
can be supported by our @system target or some minimal subset of @world.  As
new package versions come out of upstream, we update this metadata with changes
to the split-usr status, and this then provides a history of the more or less
amount of difficulty needed to maintain support for split-usr, and *then*, we
can make an objective decision to continue supporting or not supporting the
capability.

As for me, I am flat out ruling out a full-reinstall of all my systems.  I have
fixed disk partition layouts on all of them that cannot be re-arranged unless I
tar up each filesystem and temporarily move it off, then rebuild the MD-RAID
and reformat the filesystems.  I am simply not going to do that on my many SGI
systems, and whatever facet of upstream, whether it's some core GNU package or
RH itself, can go pound sand for all I care.  I'll go back to a static /dev and
I'll manually mknod any missing devices if I have to.

You know it's getting ridiculous when you can maintain a Windows/NTFS partition
layout easier than a Linux one.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] usr merge

[James Le Cuirot]

On Sun, 10 Apr 2016 02:09:35 +0200
"J. Roeleveld"  wrote:

> I actually write my own initramfs because neither dracut not
> genkernel end up with a convenient boot system.
> 
> I have 2 disks, both encrypted.
> I prefer only to enter the decryption password once. Both Dracut and
> Genkernel insist on asking for the password/key for every single disk.

Dracut on RHEL actually handles this out of the box. Might be worth
finding out how.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpwkCLInTFjv.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[J. Roeleveld]

On Saturday, April 09, 2016 09:07:46 PM Rich Freeman wrote:
> On Sat, Apr 9, 2016 at 8:09 PM, J. Roeleveld  wrote:
> > I actually write my own initramfs because neither dracut not genkernel end
> > up with a convenient boot system.
> > 
> > I have 2 disks, both encrypted.
> > I prefer only to enter the decryption password once. Both Dracut and
> > Genkernel insist on asking for the password/key for every single disk.
> 
> You can of course roll your own, but I imagine that it would be more
> straightforward to just write your own dracut plugin.  They're
> basically just scripts that run at whatever boot stage you define.
> You might also just be able to modify the existing plugin.

Possibly, but that will take longer than it took to create my own.
The config-file is 181 lines. Mostly copied from an example.
The init-file is 45 lines.

And it can be easily maintained.

--
Joost

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 10/04/16 04:49, Rich Freeman wrote:
> 1. As you point out, its not a package.  That means it works
> differently than everything else, and it can't be used as a
> dependency/etc.
> 2. Genkernel's initramfs isn't all that great.  Don't get me wrong -
> it was very good back when it was new.  However, I find it hard to
> compare it to the likes of dracut.
>
> However, if it were all that serious of an issue somebody would have
> fixed it by now.  Manually building a kernel and using dracut is easy
> enough, and of course some prefer to not use an initramfs if their
> configuration allows it.
>
I haven't dared explore dracut because last I heard it was still
experimental. That people are actively using it (presumably in
production and not just experimental/development suggests at the very
least that the appropriate Gentoo wiki article needs updating (no
surprise there!).

Perhaps indeed genkernel needs some updating. When I last looked at the
best means of creating an initramfs, it was the least of the evils, but
there did seem a genuine lack of tools to accomplish it, which is where
I assume dracut came about.

Fundamentally, acknowledging a tangent of the original thread, I'd say
the jury remains out on whether Gentoo should be forcing the need of an
initramfs/rd on its users by default anyway. That kind of thing,
however, is of course, subject to a Council ruling if appropriate :) .



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 11:28 PM, M. J. Everitt  wrote:
> Ok I'm gonna push the Big Red Button here, and assume you may not have
> met 'genkernel' ..

Genkernel has been around for a LONG time.  I'm well aware of it.

> ok its not a package, but its the nearest thing to
> Gentoo's solution to what you're suggesting ... And it's in the Handbook
> .. so, where's the issue, again?!

1. As you point out, its not a package.  That means it works
differently than everything else, and it can't be used as a
dependency/etc.
2. Genkernel's initramfs isn't all that great.  Don't get me wrong -
it was very good back when it was new.  However, I find it hard to
compare it to the likes of dracut.

However, if it were all that serious of an issue somebody would have
fixed it by now.  Manually building a kernel and using dracut is easy
enough, and of course some prefer to not use an initramfs if their
configuration allows it.

-- 
Rich

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 10/04/16 04:08, Rich Freeman wrote:
> I think the bigger issue with the kernel is the huge configuration
> space it has.  Chromium may have a ton of USE flags compared to most
> packages, but those pale in comparison to the kernel.  Obviously it
> would not make sense to try to create a USE flag for every
> configuration option.  Now, a package that built and installed a
> kernel might have a few USE flags.  For example, it might have flags
> equivalent to the gentoo config add-ons (for openrc/systemd, and so
> on).  It might also have flags that give it some default
> configuration, or an all-modules configuration, or an all-builtin
> configuration.  I imagine that most distros ship something close to an
> all-modules config.
>
> In any case, that isn't really any kind of policy issue.  For whatever
> reason nobody has bothered to create a package.  Certainly nobody
> would object to somebody adding a new kernel package that builds and
> installs a fully configured kernel.  It might even become the
> recommended default in the kernel (without getting rid of the other
> options).
>
Ok I'm gonna push the Big Red Button here, and assume you may not have
met 'genkernel' .. ok its not a package, but its the nearest thing to
Gentoo's solution to what you're suggesting ... And it's in the Handbook
.. so, where's the issue, again?!



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 10:17 PM, M. J. Everitt  wrote:
> I take your point, but I would argue that the kernel and boot subsystem
> really are special cases .. you don't go hacking around the chromium
> sources to fundamentally alter the way/order it works, right?! Likewise,
> if you don't like chromium, you might install firefox .. cf. say, Lilo
> and grub. It is the flexibility (and, I concede, the complexity, and
> hence 'power') that defines Gentoo here.
>

I think the bigger issue with the kernel is the huge configuration
space it has.  Chromium may have a ton of USE flags compared to most
packages, but those pale in comparison to the kernel.  Obviously it
would not make sense to try to create a USE flag for every
configuration option.  Now, a package that built and installed a
kernel might have a few USE flags.  For example, it might have flags
equivalent to the gentoo config add-ons (for openrc/systemd, and so
on).  It might also have flags that give it some default
configuration, or an all-modules configuration, or an all-builtin
configuration.  I imagine that most distros ship something close to an
all-modules config.

In any case, that isn't really any kind of policy issue.  For whatever
reason nobody has bothered to create a package.  Certainly nobody
would object to somebody adding a new kernel package that builds and
installs a fully configured kernel.  It might even become the
recommended default in the kernel (without getting rid of the other
options).

-- 
Rich

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 10/04/16 03:06, Rich Freeman wrote:
>
> By that argument, when you run emerge chromium shouldn't it just dump
> the chromium sources in /usr/src, so that you can build and install
> your own chromium?
>
> The whole point of a source-based package manager is that it actually
> BUILDs the packages.  Why do we treat the kernel differently from
> every single other package?
>
> I get that users often want to build their own, and that is fine.  We
> SHOULD have a package that dumps sources in /usr/src (though to be
> honest I prefer to just fetch mine using git).  However, why shouldn't
> emerge virtual/kernel not just give you a /boot/vmlinux-x.y.z the same
> way that emerge vim gives you a /usr/bin/vim?
>
I take your point, but I would argue that the kernel and boot subsystem
really are special cases .. you don't go hacking around the chromium
sources to fundamentally alter the way/order it works, right?! Likewise,
if you don't like chromium, you might install firefox .. cf. say, Lilo
and grub. It is the flexibility (and, I concede, the complexity, and
hence 'power') that defines Gentoo here.

This also applies to the whole /usr debate .. and yes, I agree there are
caveats with both our existing setup and many of the others discussed on
this thread. I think there is a debate to be had, and whilst it has born
the inevitable bike-shedding, I think there could be some merit in a
'flattened' system. I suppose the natural follow-on question from this,
is "how best to achieve it?".



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 9:35 PM, M. J. Everitt  wrote:
> I think that is the potential for a stage4-style install. I think
> previous list discussions have maintained that the flexibility of gentoo
> is maintained by having a very basic install image, and a stage3 to
> bootstrap into, and have the user compile their own kernel.
>
> Otherwise, go install debian/ubuntu/choose-your-own-ready-boxed-linux
> ... gentoo isn't that kinda distro. Imho.

By that argument, when you run emerge chromium shouldn't it just dump
the chromium sources in /usr/src, so that you can build and install
your own chromium?

The whole point of a source-based package manager is that it actually
BUILDs the packages.  Why do we treat the kernel differently from
every single other package?

I get that users often want to build their own, and that is fine.  We
SHOULD have a package that dumps sources in /usr/src (though to be
honest I prefer to just fetch mine using git).  However, why shouldn't
emerge virtual/kernel not just give you a /boot/vmlinux-x.y.z the same
way that emerge vim gives you a /usr/bin/vim?


-- 
Rich

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 10/04/16 02:14, Rich Freeman wrote:
> Part of me also wonders if Gentoo would be better off having emerge
> gentoo-sources actually BUILD the kernel and initramfs and not just
> dump a bunch of sources on the disk.  Most distros consider an
> initramfs a no-brainer because it just ships already setup, and an
> initramfs is a lot more forgiving when you add a new drive and your
> firmware/kernel decides to re-number everything.  Just label your
> filesystems or store UUIDs and the initramfs will figure out what
> happened.
>
I think that is the potential for a stage4-style install. I think
previous list discussions have maintained that the flexibility of gentoo
is maintained by having a very basic install image, and a stage3 to
bootstrap into, and have the user compile their own kernel.

Otherwise, go install debian/ubuntu/choose-your-own-ready-boxed-linux
... gentoo isn't that kinda distro. Imho.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 8:37 PM, M. J. Everitt  wrote:
> I may have contributed to the latter point, but addressing the former
> specifically, I, like others, have /usr mounted on an NFS server for
> thin clients (not in the full-true sense, but with a very minimal /
> currently residing on USB).
> What you propose moving binaries from / to /usr would render them
> completely unbootable without early mounting via initramfs.

I believe dracut will auto-mount /usr.  As long as your fstab is
accurate (double-check - sometimes people don't have correct settings
for root since without something like dracut the root filesystem isn't
mounted according to fstab), I suspect it will just NFS-mount your
/usr before pivoting.  If not you can probably use the fstab-user
module to force it to mount (you stick a second dracut-specific fstab
file in /etc and it will mount everything it finds in there whether it
thinks it needs it or not).  I'd start with the auto-magic detection
since it tends to work.

Dracut needs a root= setting on the kernel command line to get it
started, but once it finds that it tends to figure out how to get it
mounted read-only, then it looks inside for an /etc/fstab to figure
out the rest.  When you build the initramfs dracut will also copy
files like mdadm.conf into the initramfs automatically.  You can also
configure it to load extra stuff in there (my initramfs doubles as a
rescue image, so I stick a few convenience things in there that
strictly aren't needed, like btrfstune and a full bash instead of just
dash).

Part of me also wonders if Gentoo would be better off having emerge
gentoo-sources actually BUILD the kernel and initramfs and not just
dump a bunch of sources on the disk.  Most distros consider an
initramfs a no-brainer because it just ships already setup, and an
initramfs is a lot more forgiving when you add a new drive and your
firmware/kernel decides to re-number everything.  Just label your
filesystems or store UUIDs and the initramfs will figure out what
happened.

-- 
Rich

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 8:09 PM, J. Roeleveld  wrote:
>
> I actually write my own initramfs because neither dracut not genkernel end up
> with a convenient boot system.
>
> I have 2 disks, both encrypted.
> I prefer only to enter the decryption password once. Both Dracut and Genkernel
> insist on asking for the password/key for every single disk.
>

You can of course roll your own, but I imagine that it would be more
straightforward to just write your own dracut plugin.  They're
basically just scripts that run at whatever boot stage you define.
You might also just be able to modify the existing plugin.

-- 
Rich

Re: [gentoo-dev] usr merge

[Gordon Pettey]

On Sat, Apr 9, 2016 at 5:50 PM, Philip Webb  wrote:

> 160409 Canek Peláez Valdés wrote:
> > On Sat, Apr 9, 2016 at 2:49 PM, Philip Webb 
> wrote:
> >> I've always used Lilo, which is simple + reliable :
> >> I never see questions re it here, but there are many re Grub.
> >> I do use recent hardware, a cutting-edge machine I built  6 mth ago .
> >> When setting it up, I suppressed UEFI in the BIOS settings :
> >> isn't that what anyone not running M$ would do ?
> > I just disabled secure boot, although it's possible to use it with Linux.
> > However, it would require to manually sign everything from boot loader
> > to kernel modules, since Gentoo has no infrastructure to do that.
> > I don't "supress" UEFI, since it's *obviously* so much better than BIOS
> > and since bootctl (the program formerly known as gummiboot)
> > it's incredible easy to use. You don't even notice it's there.
>
> Sorry, I meant "suppress secure boot".  My mobo doesn't have UEFI.


If you have "secure boot", you have UEFI. You can't have it without.

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 10/04/16 00:53, William Hubbs wrote:
>
> The original discussion was about the usr merge [1], which is taking the
> binary parts of / and putting them in /usr, then inserting symlinks in /
> to preserve backward compatibility. Yes, I'm pointing to a document on
> fdo, but the systemd guys have nothing to do with the /usr merge; it
> originally happened in Solaris.
>
> I never supported the reverse merge that has been discussed, it was just
> brought up I guess as an example of a Gentoo user being able to do his
> own setup. Reverse merge meaning moving everything from /usr to /.
>
I may have contributed to the latter point, but addressing the former
specifically, I, like others, have /usr mounted on an NFS server for
thin clients (not in the full-true sense, but with a very minimal /
currently residing on USB).
What you propose moving binaries from / to /usr would render them
completely unbootable without early mounting via initramfs. Granted,
what I have now is rather a bodge, but it's working fine, and provided I
am meticulous about any rare changes from the host build system to /,
this is a small problem in the grander scheme of things, and I have one
maintained 'install' on my build system. Ok, so a full thin-client would
probably be a better* option, but I'm running with what I got, rather
than investing a lot (of/more) time/energy in getting that solution
working, which failed on (several) previous attempts (hence *).



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[J. Roeleveld]

On Saturday, April 09, 2016 05:15:08 PM James Le Cuirot wrote:
> On Sat, 9 Apr 2016 12:09:38 -0400
> 
> waltd...@waltdnes.org wrote:
> > > I never really got the mentality that using an initramfs is a
> > > burden.
> > > 
> >   One more piece of software that can go wrong.  You have to
> > 
> > maintain+configure it; e.g. sync software and library versions with
> > what's on the rest of the system.
> 
> Errm, have you ever actually used dracut?
> 
> dracut --kver 4.5
> 
> Wow, that was hard! It requires zero configuration and that's true even
> if you've got LVM on top of LUKS on top of RAID or something equally
> complex. If you're already running that kernel version, you don't even
> need to specify it.

I actually write my own initramfs because neither dracut not genkernel end up 
with a convenient boot system.

I have 2 disks, both encrypted.
I prefer only to enter the decryption password once. Both Dracut and Genkernel 
insist on asking for the password/key for every single disk.

The ONLY reason why I feel an initramfs is warranted is because of the 
encryption. Without that, it should not be necessary.

--
Joost

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] usr merge

[William Hubbs]

Hi Philip,

On Sat, Apr 09, 2016 at 06:50:49PM -0400, Philip Webb wrote:
> Can you or anyone else answer my other question re the origin of the thread ?
> -- ie is this a revival of not putting  /usr  on its own partition
> or is it a new proposal to alter the file system in some other way ?

The original discussion was about the usr merge [1], which is taking the
binary parts of / and putting them in /usr, then inserting symlinks in /
to preserve backward compatibility. Yes, I'm pointing to a document on
fdo, but the systemd guys have nothing to do with the /usr merge; it
originally happened in Solaris.

I never supported the reverse merge that has been discussed, it was just
brought up I guess as an example of a Gentoo user being able to do his
own setup. Reverse merge meaning moving everything from /usr to /.

The thread has definitely gotten more out of hand than I anticipated. It
is very hard at this point to separate the pros/cons, bikeshedding and
personal preferences. That's why I requested that someone assist with a
summary. :-)

William

https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/


signature.asc
Description: Digital signature

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 09/04/16 23:50, Philip Webb wrote:
> 160409 Canek Peláez Valdés wrote:
>> On Sat, Apr 9, 2016 at 2:49 PM, Philip Webb  wrote:
>>> I've always used Lilo, which is simple + reliable :
>>> I never see questions re it here, but there are many re Grub.
>>> I do use recent hardware, a cutting-edge machine I built  6 mth ago .
>>> When setting it up, I suppressed UEFI in the BIOS settings :
>>> isn't that what anyone not running M$ would do ?
>> I just disabled secure boot, although it's possible to use it with Linux.
>> However, it would require to manually sign everything from boot loader
>> to kernel modules, since Gentoo has no infrastructure to do that.
>> I don't "supress" UEFI, since it's *obviously* so much better than BIOS
>> and since bootctl (the program formerly known as gummiboot)
>> it's incredible easy to use. You don't even notice it's there.
> Sorry, I meant "suppress secure boot".  My mobo doesn't have UEFI.
>
>> I believe there are motherboards where you don't have the option
>> to "supress" UEFI, since they simply don't have BIOS anymore.
>> Seriously, UEFI is s much better.
> Thanks for the enlightment (smile).
>
> Can you or anyone else answer my other question re the origin of the thread ?
> -- ie is this a revival of not putting  /usr  on its own partition
> or is it a new proposal to alter the file system in some other way ?
>
Philip, the discussion was prompted from this original message by WilliamH:

https://archives.gentoo.org/gentoo-dev/message/df3c1494ea49191d4e3d442e37eb8ca2

Basically there is a desire to either (1) move /bin, /sbin to /usr/bin,
/usr/sbin or (2) the reverse (ie. eliminate /usr) for a variety of
reasons, but predominately to offer "more users more choice", and uphold
the principle of Gentoo being a distro of flexibility.

Whilst there is some good pros/cons being aired, there is also the usual
amount of gentoo bike-shedding, and personal preference distorting the
discussion :) .



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[Philip Webb]

160409 Canek Peláez Valdés wrote:
> On Sat, Apr 9, 2016 at 2:49 PM, Philip Webb  wrote:
>> I've always used Lilo, which is simple + reliable :
>> I never see questions re it here, but there are many re Grub.
>> I do use recent hardware, a cutting-edge machine I built  6 mth ago .
>> When setting it up, I suppressed UEFI in the BIOS settings :
>> isn't that what anyone not running M$ would do ?
> I just disabled secure boot, although it's possible to use it with Linux.
> However, it would require to manually sign everything from boot loader
> to kernel modules, since Gentoo has no infrastructure to do that.
> I don't "supress" UEFI, since it's *obviously* so much better than BIOS
> and since bootctl (the program formerly known as gummiboot)
> it's incredible easy to use. You don't even notice it's there.

Sorry, I meant "suppress secure boot".  My mobo doesn't have UEFI.

> I believe there are motherboards where you don't have the option
> to "supress" UEFI, since they simply don't have BIOS anymore.
> Seriously, UEFI is s much better.

Thanks for the enlightment (smile).

Can you or anyone else answer my other question re the origin of the thread ?
-- ie is this a revival of not putting  /usr  on its own partition
or is it a new proposal to alter the file system in some other way ?

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca

Re: [gentoo-dev] usr merge

[Canek Peláez Valdés]

On Sat, Apr 9, 2016 at 2:49 PM, Philip Webb  wrote:
> 160409 Canek Peláez Valdés wrote:
>> You use LILO : that means, you don't use UEFI :
>> that means, almost certainly, you don't use recent hardware.
>
> I've always used Lilo, which is simple + reliable :
> I never see questions re it here, but there are many re Grub.
> I do use recent hardware, a cutting-edge machine I built  6 mth ago .
> When setting it up, I suppressed UEFI in the BIOS settings :
> isn't that what anyone not running M$ would do ?

I just disabled secure boot, although it's possible to use it with
Linux. However it would require to manually sign everything from boot
loader to kernel modules, since Gentoo has no infrastructure to do
that. Maybe a future project.

I don't "supress" UEFI, since it's *obviously* so much better than
BIOS, and since bootctl (the program formerly known as gummiboot) it's
incredible easy to use. You don't even notice it's there.

Also, I'm not sure, but I believe there are motherboards where you
don't have the option to "supress" UEFI, since they simply don't have
BIOS anymore. I could be wrong; but even if that's the case, I'm
pretty sure in the future BIOS will get relegated to a niche market,
if it doesn't completely disappear.

Seriously, UEFI is s much better.

Regards.
-- 
Dr. Canek Peláez Valdés
Profesor de Carrera Asociado C
Departamento de Matemáticas
Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 09/04/16 20:53, Rich Freeman wrote:
> On Sat, Apr 9, 2016 at 3:49 PM, Philip Webb  wrote:
>> I've always used Lilo, which is simple + reliable :
>> I never see questions re it here, but there are many re Grub.
>> I do use recent hardware, a cutting-edge machine I built  6 mth ago .
>> When setting it up, I suppressed UEFI in the BIOS settings :
>> isn't that what anyone not running M$ would do ?
> That depends on how much you care about rootkits...  :)
>
Rootkits in linux ... why?!



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 3:49 PM, Philip Webb  wrote:
> I've always used Lilo, which is simple + reliable :
> I never see questions re it here, but there are many re Grub.
> I do use recent hardware, a cutting-edge machine I built  6 mth ago .
> When setting it up, I suppressed UEFI in the BIOS settings :
> isn't that what anyone not running M$ would do ?

That depends on how much you care about rootkits...  :)

-- 
Rich

Re: [gentoo-dev] usr merge

[Philip Webb]

160409 Canek Peláez Valdés wrote:
> You use LILO : that means, you don't use UEFI :
> that means, almost certainly, you don't use recent hardware.

I've always used Lilo, which is simple + reliable :
I never see questions re it here, but there are many re Grub.
I do use recent hardware, a cutting-edge machine I built  6 mth ago .
When setting it up, I suppressed UEFI in the BIOS settings :
isn't that what anyone not running M$ would do ?
 
> Gentoo devs only are saying that if by having separated /usr
> without an initramfs, you risk screwing your system.

I haven't been reading this long thread -- merely skimming some of it -- ,
& I missed or didn't understand what is being proposed or imposed.
There was an issue earlier re not having  /use  on a separate partition
& both my machines have it on the same partition as  / .
Is this thread re that earlier matter or is it a new item ?

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca

Re: [gentoo-dev] usr merge

[netfab]

Le 09/04/16 à 17:15, James Le Cuirot a tapoté :
> Errm, have you ever actually used dracut?
> 
> dracut --kver 4.5
> 
> Wow, that was hard! It requires zero configuration [...]

Sorry. Not true.

> $ emerge -pv dracut
> 
> [...]
>
> The following keyword changes are necessary to proceed:
>  (see "package.accept_keywords" in the portage(5) man page for more
> details) # required by dracut (argument)
> =sys-kernel/dracut-044 ~amd64

Re: [gentoo-dev] usr merge

[Alexis Ballier]

On Saturday, April 9, 2016 5:11:30 PM CEST, William Hubbs wrote:

...

if we don't make it optional we're going to cause some serious headaches
for people who are invested in the current status quo.
 ...


gen_usr_ldscript is only needed if you are using separate /usr without
an initramfs. This is unsupported and orthogonal to the usr merge.


just one addition: for having self-contained / with /usr on another 
partition, you just need to move libfoo.so* to /lib; the ldscript is only 
useful because the linker searches /usr/lib first then /lib, and if 
libfoo.a is in /usr/lib, it picks that one.
IOW: gen_usr_ldscript is not needed without static libs, even for the case 
you describe

Re: [gentoo-dev] usr merge

[Consus]

On 17:15 Sat 09 Apr, James Le Cuirot wrote:
> On Sat, 9 Apr 2016 12:09:38 -0400
> waltd...@waltdnes.org wrote:
> 
> > > I never really got the mentality that using an initramfs is a
> > > burden.  
> > 
> >   One more piece of software that can go wrong.  You have to
> > maintain+configure it; e.g. sync software and library versions with
> > what's on the rest of the system.
> 
> Errm, have you ever actually used dracut?
> 
> dracut --kver 4.5
> 
> Wow, that was hard! It requires zero configuration and that's true even
> if you've got LVM on top of LUKS on top of RAID or something equally
> complex. If you're already running that kernel version, you don't even
> need to specify it.

In 2014 I switched from dracut to genkernel because after *every*
dracut's update I was writing to it's devs about a new shiny bug. Like
infinite loops in the pidof() implementation.

Re: [gentoo-dev] usr merge

[James Le Cuirot]

On Sat, 9 Apr 2016 12:09:38 -0400
waltd...@waltdnes.org wrote:

> > I never really got the mentality that using an initramfs is a
> > burden.  
> 
>   One more piece of software that can go wrong.  You have to
> maintain+configure it; e.g. sync software and library versions with
> what's on the rest of the system.

Errm, have you ever actually used dracut?

dracut --kver 4.5

Wow, that was hard! It requires zero configuration and that's true even
if you've got LVM on top of LUKS on top of RAID or something equally
complex. If you're already running that kernel version, you don't even
need to specify it.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpyPYehoZmgo.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[waltdnes]

On Sat, Apr 09, 2016 at 07:11:31AM -0400, Rich Freeman wrote

> It was simply a recognition that we were already in a state where
> booting a system without /usr mounted early can cause problems.

  For certain edge cases... yes.  But they were already using initramfs
or merging /usr into /.  I'm talking about the 95% who don't really need
it.

> I never really got the mentality that using an initramfs is a burden.

  One more piece of software that can go wrong.  You have to
maintain+configure it; e.g. sync software and library versions with
what's on the rest of the system.

> An initramfs is just a secondary bootloader for userspace.  I almost
> always use them even if I'm just booting a VM with a single partition
> on it.  If something goes wrong you can fall back to a shell in the
> initramfs and it is like having a rescue disk built into your system
> disk.

  There is single-user mode for rescue.

> For a more complex setup it is much more robust than relying on
> the kernel to find your root, and it also lets you build with a more
> module-based kernel, which has some benefits as well even if you build
> kernels tailored to each host.

  I have "Production" and "Experimental" entries in my LILO menu.  A new
kernel is always set up as the "Experimental" entry.  After running
several days without problems, I run a script which copies the data from
the "Experimental" portion to "Production".

  The only time my system had problems "finding root" was years ago when
the switch from /dev/hd* to /dev/sd* took place.  The "Experimental"
boot with the new kernel died.  I booted "Production", read the mailing
list, changed "hd" to "sd" for the "Experimental" entry, and rebooted.
After several days without problems, I made the same change to the
"Production" entry, and copied the "Experimental" portion to
"Production".

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] usr merge

[William Hubbs]

On Sat, Apr 09, 2016 at 12:06:47AM -0400, Anthony G. Basile wrote:
> 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 of the fact
> > that many distros actually do it this way already?
> 
> RBAC policy files for one.  You'll probably break every single hardened
> gentoo server out there.
 
 Tell me more about this; I don't know a lot about what would break.
 Also, are you sure it would break, or are you just thinking that it
 would?

> scripts and programs that assume different executables with the same
> name at different points along the path, eg I know a company where
> they've set up an ssh wrapper at /usr/local/bin/ssh which wrap /usr/bin/ssh.
 
 This won't break, because /usr/bin/ssh would still exist as it does and
 /usr/local is not touched.

File colissions between the directories that are being merged would
definitely be an issue that needs to be worked out before this could
happen, and I understand that. I know of at least one, and we would need
to find out if there are others.

Forgetting about /usr/local since we don't control that, this type of
file name collision across the bin directories is not good whether or
not you merge /usr. It would cause issues in path name resolution.

> security measures where you don't dereference sym links along $PATH
> because sym links can be used in various types of exploits.
 
Every amd64 gentoo system already has one of these, the "lib" symlink,
both in / and /usr, so if you aren't dereferencing symlinks, aren't you
already broken?

> > 
> > I don't really have a problem with making it optional or the default.
> 
> if we don't make it optional we're going to cause some serious headaches
> for people who are invested in the current status quo.
> 
> > 
> > It can also be left up to the maintainers, and of course somebody
> > could even fork baselayout/etc if they wish and virtualize it in
> > @system.  Most things in Gentoo don't actually require a consensus to
> > move forward, especially if they aren't defaults.
> 
> if we deprecate the linker scripts in /usr/lib by stubbing out
>gen_usr_ldscript, then its not as simple as "maintainer's choice".

gen_usr_ldscript is only needed if you are using separate /usr without
an initramfs. This is unsupported and orthogonal to the usr merge.
 
> > 
> > In any case, what is the point of this thread?  If somebody wants to
> > implement a merged /usr what exactly is stopping them from doing so?
> 
> i'm against something that doesn't maintain backwards compat.

If there are ways that merging / into /usr does not maintain backward
compatibility, I want to know what they are.

This is not directed at anyone specifically, it is just a general
comment.

I've seen a lot of speculation on this thread about what might break,
and a lot of comments about a perceived removal  of choice.

Can someone help get a summary together? let's get a single message
summarizing everything.

Thanks,

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] usr merge

[Ian Stakenvicius]

> On Apr 8, 2016, at 8:42 PM, William Hubbs  wrote:
> 
>> 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, however, that's not enough to make deployment across
>> multiple machines super simple. The distros that focus on that aren't
>> rolling release like we are, and thus don't face the same difficulties
>> that we do. In addition, Gentoo supports a broad number of choices for
>> users and some are advocating for an option.
> 
> 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.
> 

Sure we do.  Users can do pretty much whatever convoluted file system hierarchy 
layout they want prior to unpacking the stage3 -- multiple volumes, symlinks or 
bind-mounts to combine dirs, etc etc.  

IMO support for this usr-merge should be left to that level of system 
configuration, as long as portage/other PMs support installing packages in such 
a way that the contents of /bin and /usr/bin don't collide with each other at 
merge time.

In other words, we should not drop any form of support at all for 
non-usr-merged systems.  Which means all of that ebuild cleanup WilliamH wants 
to do cannot happen.  Which, IMO, makes the whole thing moot.

Re: [gentoo-dev] usr merge

[Luca Barbato]

On 09/04/16 14:37, Rich Freeman wrote:
> I've certainly haven't had many problems with dracut.  When it fails
> it is usually because I'm doing something ELSE that is off-the-wall
> and it just doesn't have a plugin for it yet.  (And in those cases it
> isn't like the kernel tends to get it right without an initramfs.)
> 
> I'd certainly want to test it on a merged /usr, but I'd be surprised
> if it doesn't work, since it was designed to run on distros that are
> using a merged /usr.

I think that should be the first thing to do not the last one =)

> In an ideal world, you might argue that / should just be a tmpfs or
> something almost as ephemeral.  It is just a place you hang everything
> else off of.

That would be the core concept, but then you can just not have /bin
/sbin /lib .

> The thing I like about the merge is that it basically puts all your
> distro-supplied stuff in one place.  /usr basically becomes the OS
> minus state.  If things started out that way and you just had a short
> stub loader that gets things initialized, and I were arguing that
> instead of that little initialization stub you should break up /usr so
> that the root count mount /usr, would that sound all that compelling?
> I think having it all in one mountpoint seems a lot more compelling. 

you cannot ever have everything in 1 mount point, you just move the
problem somewhere else you notice less (initramfs), but the problem
remains and either is solved or not.

having everything in /usr and then copy it over ${somewhere} is there,
it can be debated if /bin or initramfs is the best place to put it.

lu

Re: [gentoo-dev] usr merge

[Luca Barbato]

On 08/04/16 14:55, Rich Freeman wrote:
> The purpose of a /usr merge is to get all the stateless stuff into one place.

beside what you have in /etc ...

usr-merge, in practice just moves early-boot/core tools where the rest
of the userspace lives.

> Some of the ultimate goals include:
> 1.  A read-only /usr

And mixing early-boot tools with post-boot userspace would help how?

> 2.  Having /usr signature-verified at boot

Because /etc is totally unimportant.

> 3.  Having everything that runs signature-checked before it is run

Because obviously you do not need to signature-check per executable.

> 4.  Having /usr shared across many containers/etc.

Because obviously it is the early-boot userspace spoiling this.

> 5.  Stateless systems - boot with a /usr and it creates the rest
> dynamically, and they're lost when the container is shut down.

Sounds backwards in many different ways.

> Put it this way, if you were designing a new OS from scratch today,
> would it make more sense to put all the distro-supplied
> binaries/libraries under a single path off the root, or off of many
> paths from the root?

You mean /usr/local ?

The whole thing ceases to be important once you have bind-mount and PATH
imho.

There is the specific need to have all the tools needed to boot in a
single place that can be accessed with ease.

It being /bin or initramfs or /boot/bin is completely cosmetic.

But you need a easy and reliable way to get it.

The idea of having / just holding the mount points and then have all the
other paths mounted by the early boot is fun only on paper I'm afraid.
(and we aren't even getting there since I bet /etc will stay in the root
partition for ages).

lu

Re: [gentoo-dev] usr merge

[Anthony G. Basile]

On 4/9/16 7:16 AM, Anthony G. Basile wrote:
> On 4/9/16 6:56 AM, Rich Freeman wrote:
>> Personally, I think our users would be better-served by making it a
>> choice.
> 
> Rich, we can bike shed for days.  It would just be nice to hear from
> base-layout people whether it will be a choice or not.  We need to know
> that so we can plan accordingly.
> 

@williamh

Is there a plan here that I can read?

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 8:27 AM, Luca Barbato  wrote:
> On 09/04/16 13:53, Rich Freeman wrote:
>> Put the very same stuff in the initramfs?  Most initramfs creation
>> scripts should already do this automatically, and with compat symlinks
>> even those that don't probably will still end up doing it anyway..
>
> The question is different: do they work reliably?
>

I've certainly haven't had many problems with dracut.  When it fails
it is usually because I'm doing something ELSE that is off-the-wall
and it just doesn't have a plugin for it yet.  (And in those cases it
isn't like the kernel tends to get it right without an initramfs.)

I'd certainly want to test it on a merged /usr, but I'd be surprised
if it doesn't work, since it was designed to run on distros that are
using a merged /usr.

> usr-merge does not solve any problem in itself (and it is totally
> backwards, if somebody wants to simplify would do /usr -> /)

I don't really have any devotion to the particular design, but half
the point of the merge is to allow /usr to be read-only, on a
filesystem remotely mounted, and so on.

In an ideal world, you might argue that / should just be a tmpfs or
something almost as ephemeral.  It is just a place you hang everything
else off of.

But, of course moving all of /usr to / solves the early boot issue.
But, if you're going to do that you might as well just put /usr on
your root filesystem and have the same thing.

The thing I like about the merge is that it basically puts all your
distro-supplied stuff in one place.  /usr basically becomes the OS
minus state.  If things started out that way and you just had a short
stub loader that gets things initialized, and I were arguing that
instead of that little initialization stub you should break up /usr so
that the root count mount /usr, would that sound all that compelling?
I think having it all in one mountpoint seems a lot more compelling.

-- 
Rich

Re: [gentoo-dev] usr merge

[Luca Barbato]

On 09/04/16 13:53, Rich Freeman wrote:
> On Sat, Apr 9, 2016 at 7:41 AM, Luca Barbato  wrote:
>> On 05/04/16 03:19, William Hubbs wrote:
>>> Thoughts on any of this?
>>
>> The whole usr-merge moves the problem of putting stuff in / to putting
>> the very same stuff in the initrd when something different from busybox
>> (or equivalent) is needed to get the early boot mounting.
>>
>> Do we have a reliable way to address this now?
>>
> 
> Put the very same stuff in the initramfs?  Most initramfs creation
> scripts should already do this automatically, and with compat symlinks
> even those that don't probably will still end up doing it anyway..

The question is different: do they work reliably?

usr-merge does not solve any problem in itself (and it is totally
backwards, if somebody wants to simplify would do /usr -> /), but makes
more evident that you might need lots of the userspace to successfully
complete your early boot.

lu

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 7:41 AM, Luca Barbato  wrote:
> On 05/04/16 03:19, William Hubbs wrote:
>> Thoughts on any of this?
>
> The whole usr-merge moves the problem of putting stuff in / to putting
> the very same stuff in the initrd when something different from busybox
> (or equivalent) is needed to get the early boot mounting.
>
> Do we have a reliable way to address this now?
>

Put the very same stuff in the initramfs?  Most initramfs creation
scripts should already do this automatically, and with compat symlinks
even those that don't probably will still end up doing it anyway..

Apologies if I missed the point of your question.  Are you looking for
a solution OTHER than an initramfs?  I imagine somebody could stick
some kind of wrapper on /, but in general if you want /usr not on the
root filesystem with a /usr merge you're going to have to jump through
hoops if you're not using an initramfs.  If you want a more
traditional configuration where / is used to mount /usr then a merged
/usr probably isn't for you.

-- 
Rich

Re: [gentoo-dev] usr merge

[Luca Barbato]

On 05/04/16 03:19, William Hubbs wrote:
> Thoughts on any of this?

The whole usr-merge moves the problem of putting stuff in / to putting
the very same stuff in the initrd when something different from busybox
(or equivalent) is needed to get the early boot mounting.

Do we have a reliable way to address this now?

If the answer is no, maybe we should focus on solving it first and then
think how to move stuff around.

lu

Re: [gentoo-dev] usr merge

[Anthony G. Basile]

On 4/9/16 6:56 AM, Rich Freeman wrote:
> Personally, I think our users would be better-served by making it a
> choice.

Rich, we can bike shed for days.  It would just be nice to hear from
base-layout people whether it will be a choice or not.  We need to know
that so we can plan accordingly.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 1:32 AM,   wrote:
>
> now - an arbitrary decree comes down that *EVERYBODY* who wants a
> separate /usr needs to have initramfs.
>

The "decree" wasn't some kind of law that the Gentoo police will come
out to your house and arrest you for violating.

It was simply a recognition that we were already in a state where
booting a system without /usr mounted early can cause problems.  There
isn't really any solution to these problems (other than moving most of
/usr into /, which I doubt is the desire of anybody who puts /usr on a
separate filesystem), and it probably will only get worse.

The intent of the resolution was to not burden package maintainers to
have to cater to a use case that was already failing.

And the wording of the resolution doesn't mention the word "initramfs"
at all, precisely because we recognized that there were many ways to
work around the problem.

If you have concerns about the decision being arbitrary you might want
to read the original summary:
https://projects.gentoo.org/council/meeting-logs/20130813-summary.txt

and log:
https://projects.gentoo.org/council/meeting-logs/20130813.txt

And of course you can read the list archives from the time where the
issue was extensively discussed.

> * IT DOES NOT MAKE THINGS ANY EASIER FOR THE ORIGINAL 5% EDGE CASES *.
> But the other 95% who could run separate /usr are now being told they
> must run initramfs "just because".  What does it accomplish?

I never really got the mentality that using an initramfs is a burden.

You can boot a kernel as an EFI program, but the reality is that many
if not most users of linux on EFI use a secondary bootloader.  Heck,
back in the old days you could actually boot linux directly from the
BIOS without any secondary bootloader, but this was so impractical
that even Linus now tells people to:
bugger_off_msg:
.ascii  "Use a boot loader.\r\n"
.ascii  "\n"
.ascii  "Remove disk and press any key to reboot...\r\n"
.byte   0
(and I must say that I admire the man with the guts to not insert a
carriage return when the carriage is already on the first column)

An initramfs is just a secondary bootloader for userspace.  I almost
always use them even if I'm just booting a VM with a single partition
on it.  If something goes wrong you can fall back to a shell in the
initramfs and it is like having a rescue disk built into your system
disk.  For a more complex setup it is much more robust than relying on
the kernel to find your root, and it also lets you build with a more
module-based kernel, which has some benefits as well even if you build
kernels tailored to each host.


-- 
Rich

Re: [gentoo-dev] usr merge

[Rich Freeman]

On Sat, Apr 9, 2016 at 12:06 AM, Anthony G. Basile  wrote:
> On 4/8/16 11:03 PM, Rich Freeman wrote:
>>
>> What problems are you anticipating, especially in light of the fact
>> that many distros actually do it this way already?
>
> RBAC policy files for one.  You'll probably break every single hardened
> gentoo server out there.

I wasn't suggesting that some adjustments to packages wouldn't be
needed to accommodate the change.  I was talking about the long-term,
after any necessary changes are made?

>
> scripts and programs that assume different executables with the same
> name at different points along the path, eg I know a company where
> they've set up an ssh wrapper at /usr/local/bin/ssh which wrap /usr/bin/ssh.

I get your point, but the actual case you cited wouldn't be affected
by a /usr merge.  I appreciate that there are cases where something
might be affected (though users shouldn't be sticking wrappers in
/usr/bin anyway without packaging them).

>>
>> I don't really have a problem with making it optional or the default.
>
> if we don't make it optional we're going to cause some serious headaches
> for people who are invested in the current status quo.

If you want to use a distro where you can heavily invest in the status
quo and not expect it to change I think you'd be better off with a
distro like RHEL, which targets this niche almost explicitly.

But, as I've said, I see no reason not to make it optional.  A big
part of why we CAN get stuff like this done is that we let people
migrate themselves at their own pace.

>>
>> It can also be left up to the maintainers, and of course somebody
>> could even fork baselayout/etc if they wish and virtualize it in
>> @system.  Most things in Gentoo don't actually require a consensus to
>> move forward, especially if they aren't defaults.
>
> if we deprecate the linker scripts in /usr/lib by stubbing out
> gen_usr_ldscript, then its not as simple as "maintainer's choice".

Well, I don't hear toolchain asking to retire that function.  If it is
their desire to stop maintaining it, then somebody else could of
course take over for them and preserve a choice.

>
>>
>> In any case, what is the point of this thread?  If somebody wants to
>> implement a merged /usr what exactly is stopping them from doing so?
>
> i'm against something that doesn't maintain backwards compat.
>

Well, we all have the freedom to fork baselayout if it isn't
maintained the way we want it to be.  Currently, no policy exists that
says the baselayout maintainers can't just maintain the package
however they want to (other than the general QA practice of
announcing/coordinating changes in advance with trackers/etc).  I
suppose if somebody wants to propose a policy that says otherwise it
is their freedom to do so.

Personally, I think our users would be better-served by making it a
choice.  That might be a choice that comes with some pros/cons, just
like the choice to use an initramfs, or the choice to run systemd, or
any other choice that we trust our users to make.

-- 
Rich

Re: [gentoo-dev] usr merge

[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 me...

before - many people successfully used separate /usr, without initramfs.
A few edge cases, e.g. people with bluetooth keyboards, had to use
initramfs if they wanted a separate /usr.  The poor darlings felt left
out because they had to do extra setup work, versus the other 95%.

now - an arbitrary decree comes down that *EVERYBODY* who wants a
separate /usr needs to have initramfs.

* IT DOES NOT MAKE THINGS ANY EASIER FOR THE ORIGINAL 5% EDGE CASES *.
But the other 95% who could run separate /usr are now being told they
must run initramfs "just because".  What does it accomplish?

BTW, I'm still running a separate /usr without initramfs, and no related
problems; thank you.  If I decided to go to an edge-case setup (e.g.
Bluetooth keyboard, or ell partitions encrypted) then I could understand
being asked to run initramfs.

This is reminiscent of the "Mozilla Mentality", where everybody is
forced to the lowest common denominator.  Yes, a desktop GUI sucks on
a tablet/smartphone; I get it.  So Firefox was saddled with the
smartphone-oriented Atrocious^H^H^H^H^H^H Australis GUI, which sucks
on a desktop.  That was the last straw that drove me to Pale Moon.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] usr merge

[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 network
> distributing it. Not that we aren't already successful with it without
> the merge though.
> 

it can also be a recipe for success if you do it right.  i did it for
years on a 20 machine classroom where i didn't feel like installing the
same thing 20 times.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] usr merge

[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 of the fact
> that many distros actually do it this way already?

RBAC policy files for one.  You'll probably break every single hardened
gentoo server out there.

scripts and programs that assume different executables with the same
name at different points along the path, eg I know a company where
they've set up an ssh wrapper at /usr/local/bin/ssh which wrap /usr/bin/ssh.

security measures where you don't dereference sym links along $PATH
because sym links can be used in various types of exploits.

really, it doesn't take much imagination to come up with scenarios where
you'll break people systems.

> 
> I don't really have a problem with making it optional or the default.

if we don't make it optional we're going to cause some serious headaches
for people who are invested in the current status quo.

> 
> It can also be left up to the maintainers, and of course somebody
> could even fork baselayout/etc if they wish and virtualize it in
> @system.  Most things in Gentoo don't actually require a consensus to
> move forward, especially if they aren't defaults.

if we deprecate the linker scripts in /usr/lib by stubbing out
gen_usr_ldscript, then its not as simple as "maintainer's choice".

> 
> In any case, what is the point of this thread?  If somebody wants to
> implement a merged /usr what exactly is stopping them from doing so?

i'm against something that doesn't maintain backwards compat.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] usr merge

[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

[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 successful with it without
the merge though.

-- 
Damien Levac

Re: [gentoo-dev] usr merge

[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 way already?

I don't really have a problem with making it optional or the default.

It can also be left up to the maintainers, and of course somebody
could even fork baselayout/etc if they wish and virtualize it in
@system.  Most things in Gentoo don't actually require a consensus to
move forward, especially if they aren't defaults.

In any case, what is the point of this thread?  If somebody wants to
implement a merged /usr what exactly is stopping them from doing so?

-- 
Rich

Re: [gentoo-dev] usr merge

[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 libraries
>>> into.
>>
>> I thought vapier was introducing a switch USE=usr-sep which allowed us
>> to keep an unmerged /usr, or are we completely eliminating this choice?
> 
> This use flag, sep-usr, has nothing to do with the /usr merge. It was
> added as a way to allow a few more people to use separate /usr
> configurations (this means/ and /usr on separate
> filesystems) without initramfs, before the council decided that all who
> have separate /usr should be using an initramfs.
> 
> Separate /usr does not preclude merging / into /usr.
> 
> William
> 

So I'm still not seeing a great gain from this merger.  It seems like
you think the linker scripts are something bad.  Why?  And you don't
seem to like that we move some things around between / and /usr for pkgs
like coreutils.  But other than coreutils, I don't know many pkgs where
we do that.

Alternatively, this may introduce problems.  So it seems like we're
fixing something that isn't broken.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] usr merge

[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 introducing a switch USE=usr-sep which allowed us
> to keep an unmerged /usr, or are we completely eliminating this choice?

This use flag, sep-usr, has nothing to do with the /usr merge. It was
added as a way to allow a few more people to use separate /usr
configurations (this means/ and /usr on separate
filesystems) without initramfs, before the council decided that all who
have separate /usr should be using an initramfs.

Separate /usr does not preclude merging / into /usr.

William


signature.asc
Description: Digital signature

Re: [gentoo-dev] usr merge

[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 during early boot we'd end up with
>> everything there.  Bluetooth keyboards is a common example.  The
>> console should work during early boot, right?
>   Seriously... how many people run Bluetooth keyboards on Gentoo anyways?
>
I know at least one person (not myself).

Re: [gentoo-dev] usr merge

[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.  Bluetooth keyboards is a common example.  The
> console should work during early boot, right?

  Seriously... how many people run Bluetooth keyboards on Gentoo anyways?

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] usr merge

[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 difference between "system software" and
> "regular applications" isn't clear-cut.

  Let me rephrase that... instead of calling it "system software", let's
call it "software that the system needs for its own purposes".  Whether
end users run them later is beside the point.  Systems will boot, mount
disks, and set TCP/IP connections fine without GIMP or Firefox.  Not so
much without mount and ifconfig/ifcfg.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] usr merge

[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 we completely eliminating this choice?

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] usr merge

[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, however, that's not enough to make deployment across
> multiple machines super simple. The distros that focus on that aren't
> rolling release like we are, and thus don't face the same difficulties
> that we do. In addition, Gentoo supports a broad number of choices for
> users and some are advocating for an option.
 
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.

We install some binaries/libraries in /{bin,sbin,lib*} and others in
/usr/{bin,sbin,lib*}; the users don't get to choose which binaries and
libraries go where.

> At a higher level, I'm not really sure why we're discussing it.
> Perhaps I missed it, but I didn't see an actual problem that someone
> was having mentioned anywhere. The /usr merge seems to me as a partial
> "solution" for a different type of environment; one that, arguably, is
> better suited for a distro that's designed for such deployments.

It would, for us, eliminate a lot of customization in the base-system
ebuilds, for example, all of the rearrangement of binaries in coreutils,
splitting of the binaries between / and /usr in procps, all calls to
gen_usr_ldscript in any ebuilds, among other things.

In short, it would make packaging simpler, and maintain backward
compatibility at the same time since the symlinks in / would exist.

> I personally think sharing /usr over a network and deploying it to
> multiple machines could be a recipe for disaster. It seems like a
> business case scenario that would involve multiple other system
> changes. It sounds like a great case for adding another profile or
> something rather than changing things tree-wide. Maybe it's a case for
> making profiles more powerful and flexible. Regardless, I'd hate to
> see choice diminished here for the sake of a single set of rather
> narrow use-cases.

Based on what I said above, I don't see what choice is being diminished
by the /usr merge, since we do not give users a choice about how their
file system is laid out, or where packages are installed.

If I'm honestly missing something, enlighten me. :-)

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] usr merge

[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
>>> 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.
>>> 
>> 
>> Keep in mind that following upstream and the /usr merge are
>> somewhat orthogonal.  You can just install those binaries in /usr
>> without merging everything over.
>> 
>> The only issue is that without the merge anybody embedding a path
>> to these binaries would have to fix their packages.  Presumably
>> to aid the transition a symlink (at the file level) would be
>> needed for some period of time.
>> 
> 
> 
> @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
> confused because debian has switched to systemd and yet has not
> merged usr.
> 

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, however, that's not enough to make deployment across
multiple machines super simple. The distros that focus on that aren't
rolling release like we are, and thus don't face the same difficulties
that we do. In addition, Gentoo supports a broad number of choices for
users and some are advocating for an option.

At a higher level, I'm not really sure why we're discussing it.
Perhaps I missed it, but I didn't see an actual problem that someone
was having mentioned anywhere. The /usr merge seems to me as a partial
"solution" for a different type of environment; one that, arguably, is
better suited for a distro that's designed for such deployments.

I personally think sharing /usr over a network and deploying it to
multiple machines could be a recipe for disaster. It seems like a
business case scenario that would involve multiple other system
changes. It sounds like a great case for adding another profile or
something rather than changing things tree-wide. Maybe it's a case for
making profiles more powerful and flexible. Regardless, I'd hate to
see choice diminished here for the sake of a single set of rather
narrow use-cases.

Just my 2¢.

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXCC6jAAoJEAEkDpRQOeFwD+kP/j1EYtnbgh/s4i4lTn14vuoY
Fj57eCsCBLNbHlEEGesLEU3EEExtJgVeSC9emuI80/nynOM8dhqUUKjtoZwwBW5R
9P5QmMQdT+ScJHPQ6CL5IKh9UeAF4IgDbrJI9rdHnrRLtlE40xWDRp8NcB5fPAc2
EfLMFRZs3HpJpVMirIVIMTHEckDlMRmYzO9aqKCnmSCx3M/nKR/SWSSQ94Acet9C
DPN6nLH42vosJv1+syNUHGqf4DLn6xTREx7DEP8fBUJuQi/wDpHbbRn8PON3WkCo
FkDqjxd3AhahUpa2LaD4t/sRmvs+tjIXfgFJ8iYzJwjRQKKZvSHRlQzUwQNnI6mS
fkunumIhcJdeWCBXegaSxouAtaua7pk+AXDLx+2ZjhxDmv/BbmC6RSPWkHo3wsMl
TVbZSB4IrDrp8l3kYd+baBEtZicNgoma4jak1MFn1COFWR2/ZqtGaOVDErW92aX2
jVQkTGTUGrFNx24ZPcvPB0OVNleoOfhh97O3EFjeOl0TnbAziGX9Z75HPegLFlLR
5dXewskG6iACR2FATlhhOgscfIVwE2LxEWw/N6lm0NbZHKTOObzP39fdu0CisAck
pXtd1WBYX349Z0ympl9PCdLd68SobBROsFHKE6rwkSLkCBadzOCxgjpEGIQOPKHu
qpXF8Z8y/Hssr4SAsxb0
=4UKO
-END PGP SIGNATURE-

Re: [gentoo-dev] usr merge

[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 everything in /
that could conceivably be needed during early boot we'd end up with
everything there.  Bluetooth keyboards is a common example.  The
console should work during early boot, right?

-- 
Rich

Re: [gentoo-dev] usr merge

[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
> http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split/
> https://news.ycombinator.com/item?id=3519952
> 
> In short, this is all a historical artifact with justifications thought
> up after the fact.

  The historical reasons may or may not exist any longer.  The question
is "what is the current situation?".  The current situation is that
there are 3 classes of software...
1) system software that is required for bootup (mount, init, etcetera)
2) system software that is usually used by root for admin purposes
3) regular applications that users use

  Question... do we really want "GIMP", "Firefox", etcetera, in the same
directory as "mount", "chroot", "login", "passwd", "ifconfig", etcetera?
I don't think so.  I want separate "system progs" versus "user progs"
directories.  There may be an argument for merging /bin and /sbin
directories (items 1 and 2 above), but user applications should be
separate.  If we move /bin and /sbin into /usr/bin, I suggest moving all
user programs to /usr/local/binuser applications should be separate.  If
we move /bin and /sbin into /usr/bin, I suggest moving all user programs
to /usr/local/bin.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] usr merge

[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" etc .. how are we granting the correct permissions for binaries ..
> just relying now on the owner and execute bits being set perfectly for
> each binary, assuming everything is arbitrarily moved to /xbin ...

If you're relying on file permissions on binaries (other than the suid
bit) you're doing it wrong.

There is no harm in a non-privileged user executing /sbin/shutdown in
the non-systemd world, because init isn't going to listen to an
unprivileged user.  In a systemd world the shutdown command will talk
to systemd via dbus and dbus will use policykit to determine whether
the message should be allowed to go through (at least, I think it is
dbus that does this, and not the message recipient, but either way it
is getting checked).

Most security is provided by the kernel and posix capabilities.  If a
process has a capability, then the kernel lets it do something.
Without that capability, simply making some system calls won't do
anything.  Policykit is an extension of this into userspace, since
userspace governs a lot of important functions.  You could view
policykit as a sort of posix capability set for userspace.

The traditional suid way of doing things blurs the lines a bit, but in
general most suid-root binaries don't rely on whether you can execute
them as a form of policy.  Usually they have some kind of internal
policy management which is more flexible.  Sure, you might be able to
keep somebody from changing their password by playing with the
permissions on /bin/passwd.  However, you're probably better off
tweaking the configuration of PAM/etc.

-- 
Rich

Re: [gentoo-dev] usr merge

[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 linux distros are going to run policykit though.  Of ...

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" etc .. how are we granting the correct permissions for binaries ..
just relying now on the owner and execute bits being set perfectly for
each binary, assuming everything is arbitrarily moved to /xbin ...


owner and x bit is not a security measure at all: if you need +x, you just 
compile your own in ~ that you'll own. what is a security measure is kernel 
refusing to give you access to ressources so that your binary does what it 
is supposed to (either standard kernel or more complex things like grsec)

Re: [gentoo-dev] usr merge

[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.  Of
> course you can have a mostly-traditional distro that doesn't, at least
> until everything wants to use dbus or whatever ends up replacing it
> once son-of-kdbus comes along and gets accepted.
>
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" etc .. how are we granting the correct permissions for binaries ..
just relying now on the owner and execute bits being set perfectly for
each binary, assuming everything is arbitrarily moved to /xbin ...

Re: [gentoo-dev] usr merge

[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 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.  Of
> course you can have a mostly-traditional distro that doesn't, at least
> until everything wants to use dbus or whatever ends up replacing it
> once son-of-kdbus comes along and gets accepted.
>
Surely, Rich, you mean init=/bin/hello-world ... ;]

Re: [gentoo-dev] usr merge

[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.

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.  Of
course you can have a mostly-traditional distro that doesn't, at least
until everything wants to use dbus or whatever ends up replacing it
once son-of-kdbus comes along and gets accepted.

-- 
Rich

Re: [gentoo-dev] usr merge

[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, don't really 'use' linux
>> in the original sense of the OS ..
> 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
> http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split/
> https://news.ycombinator.com/item?id=3519952
>
> In short, this is all a historical artifact with justifications thought
> up after the fact.
>
> William
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 .. ! :]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[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 sense of the OS ..

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
http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split/
https://news.ycombinator.com/item?id=3519952

In short, this is all a historical artifact with justifications thought
up after the fact.

William


signature.asc
Description: Digital signature

Re: [gentoo-dev] usr merge

[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 feeder where experimental technologies are previewed/developed.
2.  It is feeding into RHEL, which is targeted at
infrequently-updating users who run in a release-based atmosphere.

The purpose of a /usr merge is to get all the stateless stuff into one place.

Some of the ultimate goals include:
1.  A read-only /usr
2.  Having /usr signature-verified at boot
3.  Having everything that runs signature-checked before it is run
4.  Having /usr shared across many containers/etc.
5.  Stateless systems - boot with a /usr and it creates the rest
dynamically, and they're lost when the container is shut down.

Any of these COULD be implemented on Gentoo, though whether it will
happen is questionable.  Some of these like #5 would require more
invasive changes to how we do things.  However, the principle of
having everything that is static in one place does make sense.

Put it this way, if you were designing a new OS from scratch today,
would it make more sense to put all the distro-supplied
binaries/libraries under a single path off the root, or off of many
paths from the root?  The main driver for having a split /usr is
legacy, IMO.  Apparently even the unix authors said that they
originally did it only because of the size of one of their disks and
they wanted root to be a secondary bootloader.

-- 
Rich

Re: [gentoo-dev] usr merge

[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 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.
  
>>>
>>> Keep in mind that following upstream and the /usr merge are somewhat
>>> orthogonal.  You can just install those binaries in /usr without
>>> merging everything over.
>>>
>>> The only issue is that without the merge anybody embedding a path to
>>> these binaries would have to fix their packages.  Presumably to aid
>>> the transition a symlink (at the file level) would be needed for
>>> some period of time.
>>
>> @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 confused because
>> debian has switched to systemd and yet has not merged usr.
> 
> Not that I'm for or against the merge but note that openSUSE, which has
> also switched to systemd, hasn't done the merge either.
> 

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.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] usr merge

[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 confused because
>> debian has switched to systemd and yet has not merged usr.
>
> Not that I'm for or against the merge but note that openSUSE, which has
> also switched to systemd, hasn't done the merge either.
>

systemd and /usr merge are also fairly orthogonal.

There are many reasons for a /usr merge, but most tend to revolve
around getting all the relatively static distro-supplied content into
a single place.  That makes it easier to make a separate filesystem,
or read-only, or signature-checked, or atomically updated, or shared,
and so on.  Some of those derivative benefits may be harder to realize
on Gentoo, but I think the principle is worth considering.

-- 
Rich

Re: [gentoo-dev] usr merge

[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
> >> 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.
> >>  
> > 
> > Keep in mind that following upstream and the /usr merge are somewhat
> > orthogonal.  You can just install those binaries in /usr without
> > merging everything over.
> > 
> > The only issue is that without the merge anybody embedding a path to
> > these binaries would have to fix their packages.  Presumably to aid
> > the transition a symlink (at the file level) would be needed for
> > some period of time.
> 
> @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 confused because
> debian has switched to systemd and yet has not merged usr.

Not that I'm for or against the merge but note that openSUSE, which has
also switched to systemd, hasn't done the merge either.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

Re: [gentoo-dev] usr merge

[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 ebuild.
>> We are deviating from upstream in this example.
>>
> 
> Keep in mind that following upstream and the /usr merge are somewhat
> orthogonal.  You can just install those binaries in /usr without
> merging everything over.
> 
> The only issue is that without the merge anybody embedding a path to
> these binaries would have to fix their packages.  Presumably to aid
> the transition a symlink (at the file level) would be needed for some
> period of time.
> 


@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 confused because
debian has switched to systemd and yet has not merged usr.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] usr merge

[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 .. so this is a false assumption.

You only need an initramfs (or some other mechanism to mount /usr
during early boot) if /usr is on a different filesystem than /.

If /usr is a separate filesystem, then Gentoo does require that it be
mounted during early boot, at least as a supported configuration.
While it is true today that with some configurations you can probably
get away with not mounting it during early boot, there is no
requirement that package maintainers support this.  That includes
system packages.

So, #2 applies to Gentoo as much as to any other distro.  That was a
topic of some debate a few years ago now.

> 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 ..

Duncan already explained much of this, but if you're relying on a
user's PATH setting to prevent security issues you're doing it wrong.
There are a number of binaries in /sbin which are completely
appropriate for a non-privileged user to execute.  Besides
non-privileged operations of binaries like btrfs or rpcinfo, there are
a bunch of misc binaries in there like usleep or zdump.

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, protected using tripwire or signature checking, and so on.
As has been pointed out the rolling release nature of Gentoo reduces
some of these benefits somewhat.  To truly get these benefits we would
also need to rethink how post-install configuration gets managed as
was already pointed out.

However, the principle is still a potentially useful one even if we
never follow-up with some of the things Fedora/etc are doing.  After a
merge the package manager has free rein over /usr, full config
management is the policy in /etc, and /var is a place for persistent
state that generally belongs to the applications themselves (but
management of this is a bit of a mix still with stuff like /var/www
and /var/bind alongside mail spools and mysql database files).

-- 
Rich

Re: [gentoo-dev] usr merge

[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 example.
>

Keep in mind that following upstream and the /usr merge are somewhat
orthogonal.  You can just install those binaries in /usr without
merging everything over.

The only issue is that without the merge anybody embedding a path to
these binaries would have to fix their packages.  Presumably to aid
the transition a symlink (at the file level) would be needed for some
period of time.

-- 
Rich

Re: [gentoo-dev] usr merge

[Raymond Jennings]

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

[Damien Levac]

> 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

[M. J. Everitt]

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

[Damien Levac]

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

[William Hubbs]

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

[Rich Freeman]

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

[M. J. Everitt]

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

[Raymond Jennings]

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

[Alexis Ballier]

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

[William Hubbs]

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

[Tom H]

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

[Alexis Ballier]

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

[Alexis Ballier]

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.

Re: [gentoo-dev] usr merge

[William Hubbs]

On Wed, Apr 06, 2016 at 05:36:09PM -0400, Richard Yao wrote:
> 
> 
> >> On Apr 6, 2016, at 4:43 PM, William Hubbs  wrote:
> >> 
> >>> On Wed, Apr 06, 2016 at 11:52:52AM -0400, Richard Yao wrote:
> >>> On 04/06/2016 10:58 AM, M. J. Everitt wrote:
> >>> What, if any, is the benefit of squashing /usr out of the equation? I
> >>> happen to have a few workstations that load their /usr off an NFS share
> >>> presently, with some bodgery-workarounds I did pre the udev notification
> >>> about initramfs's which I have never got around to implementing
> >>> (although I'm pretty sure I have the tools now to do, along with UUIDs
> >>> for boot media).
> >> 
> >> The idea in Solaris is to enable atomic updates via the /usr mount
> >> without touching data files in /etc or temporary files in /var. Usually,
> >> this would be done on reboot and could be propagated to many systems
> >> either via /usr on NFS or ZFS send/recv.
> >> 
> >> This works well on Solaris because both software versions are pegged
> >> (such that file formats in /etc are stable) in favor of backported fixes
> >> and the FHS does not change across major OS versions. The same goes for
> >> RHEL.
> > 
> > Also, there are other benefits to the /usr merge [1].
> 
> Are they worth breaking existing systems that are configured the one way we 
> all know things will break if this is forced? If not, a USE flag would work.

Other than systems using separate /usr without initramfs (which we
declared broken three years ago), I'm not following what "we all know"
would break.

> 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.
> 
> > 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.
> 
> >> Gentoo systems managed this way will suffer from multiple problems:
> >> 
> >> * Software updates that change the configuration file format without
> >> supporting the older format will break.
> >> 
> >> * Software updates that change the boot scripts will break.
> >> 
> >> * Future baselayout updates will not be able to touch anything outside
> >> of /usr and anything requiring such things be touched will break.
> >> 
> >> * An update to /usr that adds new software will fail to include things
> >> outside of /usr, like the boot scripts and configuration files.
> >> 
> >> * The package database will fall out of sync with /usr (or be broken
> >> period). Presumably, if you are updating this way, you should expect the
> >> package database to be broken.
> >> 
> >> These are likely to be mostly fixable, but I do not think we have a plan
> >> in place to fix them right now. The general staleness of Solaris and
> >> RHEL handle the first 3 issues for them for free.
> >> 
> >> I have not looked at the specifics of how Solaris handles the 4th, but I
> >> know that SMF in OpenSolaris descendents will update manifests on first
> >> boot into a new boot environment. That suggests to me that the Solaris
> >> boot scripts handle it by comparing /etc with /usr.
> >> 
> >> As for the 5th, the package database is not broken in Solaris zones
> >> where the /usr merge is leveraged to enable easy updates. However, I do
> >> not know how updating all zones works when zones have independently
> >> installed software. It might be that the software is installed in
> >> /usr/local inside the zone and conflicts are the user's problem, but it
> >> has been so long since I used an illumos distribution (which is
> >> descended from OpenSolaris) that I do not remember.
> > 
> > I don't think any of these issues are issues that Gentoo systems
> > managed like this do not already have.
> 
> That is my point.
 
Then we agree that these issues are not regressions that the usr merge
would cause. They are issues possibly, but imo not relevant to whether we
go ahead with the /usr merge or not.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] usr merge

[Richard Yao]

>> On Apr 6, 2016, at 4:43 PM, William Hubbs  wrote:
>> 
>>> On Wed, Apr 06, 2016 at 11:52:52AM -0400, Richard Yao wrote:
>>> On 04/06/2016 10:58 AM, M. J. Everitt wrote:
>>> What, if any, is the benefit of squashing /usr out of the equation? I
>>> happen to have a few workstations that load their /usr off an NFS share
>>> presently, with some bodgery-workarounds I did pre the udev notification
>>> about initramfs's which I have never got around to implementing
>>> (although I'm pretty sure I have the tools now to do, along with UUIDs
>>> for boot media).
>> 
>> The idea in Solaris is to enable atomic updates via the /usr mount
>> without touching data files in /etc or temporary files in /var. Usually,
>> this would be done on reboot and could be propagated to many systems
>> either via /usr on NFS or ZFS send/recv.
>> 
>> This works well on Solaris because both software versions are pegged
>> (such that file formats in /etc are stable) in favor of backported fixes
>> and the FHS does not change across major OS versions. The same goes for
>> RHEL.
> 
> Also, there are other benefits to the /usr merge [1].

Are they worth breaking existing systems that are configured the one way we all 
know things will break if this is forced? If not, a USE flag would work.

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.

> 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.

>> Gentoo systems managed this way will suffer from multiple problems:
>> 
>> * Software updates that change the configuration file format without
>> supporting the older format will break.
>> 
>> * Software updates that change the boot scripts will break.
>> 
>> * Future baselayout updates will not be able to touch anything outside
>> of /usr and anything requiring such things be touched will break.
>> 
>> * An update to /usr that adds new software will fail to include things
>> outside of /usr, like the boot scripts and configuration files.
>> 
>> * The package database will fall out of sync with /usr (or be broken
>> period). Presumably, if you are updating this way, you should expect the
>> package database to be broken.
>> 
>> These are likely to be mostly fixable, but I do not think we have a plan
>> in place to fix them right now. The general staleness of Solaris and
>> RHEL handle the first 3 issues for them for free.
>> 
>> I have not looked at the specifics of how Solaris handles the 4th, but I
>> know that SMF in OpenSolaris descendents will update manifests on first
>> boot into a new boot environment. That suggests to me that the Solaris
>> boot scripts handle it by comparing /etc with /usr.
>> 
>> As for the 5th, the package database is not broken in Solaris zones
>> where the /usr merge is leveraged to enable easy updates. However, I do
>> not know how updating all zones works when zones have independently
>> installed software. It might be that the software is installed in
>> /usr/local inside the zone and conflicts are the user's problem, but it
>> has been so long since I used an illumos distribution (which is
>> descended from OpenSolaris) that I do not remember.
> 
> I don't think any of these issues are issues that Gentoo systems
> managed like this do not already have.

That is my point.

> If you are mounting /usr from nfs right now, for example,
> things are worse, because you also have to worry about whether packages
> split their installations between /usr/lib*->/lib* and
> /usr/{,s}bin->/{s,}bin.

Only a masochist would want to do this right now. There are saner ways of doing 
things with the legacy layout than the Solaris way that depends on the /usr 
merge.

>>> Whilst these aren't currently scheduled for upgrade, I don't personally
>>> see any merit, given discussions here about work needed to 'shore up' a
>>> change to match some particular use case. I would therefore definitely
>>> agree with those that have proposed that this is an Option and not a
>>> standard gentoo install item unless there are some specific caveats that
>>> this 

Re: [gentoo-dev] usr merge

[William Hubbs]

On Wed, Apr 06, 2016 at 11:52:52AM -0400, Richard Yao wrote:
> On 04/06/2016 10:58 AM, M. J. Everitt wrote:
> > What, if any, is the benefit of squashing /usr out of the equation? I
> > happen to have a few workstations that load their /usr off an NFS share
> > presently, with some bodgery-workarounds I did pre the udev notification
> > about initramfs's which I have never got around to implementing
> > (although I'm pretty sure I have the tools now to do, along with UUIDs
> > for boot media).
> 
> The idea in Solaris is to enable atomic updates via the /usr mount
> without touching data files in /etc or temporary files in /var. Usually,
> this would be done on reboot and could be propagated to many systems
> either via /usr on NFS or ZFS send/recv.
> 
> This works well on Solaris because both software versions are pegged
> (such that file formats in /etc are stable) in favor of backported fixes
> and the FHS does not change across major OS versions. The same goes for
> RHEL.

Also, there are other benefits to the /usr merge [1]. 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.

> 
> Gentoo systems managed this way will suffer from multiple problems:
> 
> * Software updates that change the configuration file format without
> supporting the older format will break.
> 
> * Software updates that change the boot scripts will break.
> 
> * Future baselayout updates will not be able to touch anything outside
> of /usr and anything requiring such things be touched will break.
> 
> * An update to /usr that adds new software will fail to include things
> outside of /usr, like the boot scripts and configuration files.
> 
> * The package database will fall out of sync with /usr (or be broken
> period). Presumably, if you are updating this way, you should expect the
> package database to be broken.
> 
> These are likely to be mostly fixable, but I do not think we have a plan
> in place to fix them right now. The general staleness of Solaris and
> RHEL handle the first 3 issues for them for free.
> 
> I have not looked at the specifics of how Solaris handles the 4th, but I
> know that SMF in OpenSolaris descendents will update manifests on first
> boot into a new boot environment. That suggests to me that the Solaris
> boot scripts handle it by comparing /etc with /usr.
> 
> As for the 5th, the package database is not broken in Solaris zones
> where the /usr merge is leveraged to enable easy updates. However, I do
> not know how updating all zones works when zones have independently
> installed software. It might be that the software is installed in
> /usr/local inside the zone and conflicts are the user's problem, but it
> has been so long since I used an illumos distribution (which is
> descended from OpenSolaris) that I do not remember.
 
I don't think any of these issues are issues that Gentoo systems
managed like this do not already have.
If you are mounting /usr from nfs right now, for example,
things are worse, because you also have to worry about whether packages
split their installations between /usr/lib*->/lib* and
/usr/{,s}bin->/{s,}bin.

> > Whilst these aren't currently scheduled for upgrade, I don't personally
> > see any merit, given discussions here about work needed to 'shore up' a
> > change to match some particular use case. I would therefore definitely
> > agree with those that have proposed that this is an Option and not a
> > standard gentoo install item unless there are some specific caveats that
> > this solves.
> 
> 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.

[1]
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/


signature.asc
Description: Digital signature

Re: [gentoo-dev] usr merge

[Richard Yao]

On 04/06/2016 12:33 PM, Richard Yao wrote:
> On 04/06/2016 12:20 PM, Alexis Ballier wrote:
>> On Wednesday, April 6, 2016 6:06:35 PM CEST, Richard Yao wrote:
>>
>>> That is unless you put per-system state in /usr/local, do symlinks to it
>>> in / and mount /usr/local as part of system boot, which is the other way
>>> of doing this. I have seen a variant of this done in asuswrt-merlin on
>>> routers.
>>
>> This doesnt seem to have anything to do with what I was describing.
>>
>> Another option I'm using a lot is nfsroot. This doesn't have the same
>> level of flexibility: running multiple hosts with nfsroot and thus
>> shared /etc/fstab tends to be annoying.
>>
 See https://fedoraproject.org/wiki/Features/UsrMove for a more complete
 discussion.
>>>
>>> That does not address the problems of supporting this configuration in a
>>> rolling release.
>>>
>>> Formats in /etc can fall out of sync with software in /usr. If boot
>>> options change, the stuff in /etc/init.d is not updated. If you add
>>> software, the update to /etc/init.d is omitted. If you have a baselayout
>>> change, it is not propagated.
>>
>> Ever heard of CONFIG_PROTECT ? :) What you describe is already what
>> happens and what most people want.
> 
> Leveraging the /usr merge to enable easier updating of multiple systems
> means that you are updating a Gentoo system image on a build server,
> snapshotting /usr both before/after the update and then distributing the
> delta on /usr to other systems without any of the changes that occurred
> outside of /usr. A proper update requires finding all of those changes
> and then applying them manually. That really is not the same thing that
> RHEL and Solaris have, where the necessity of propagating changes
> outside of /usr is minimized by having none to propagate.

After thinking about it some more, maybe git can be (ab)used to do this
by having the image's root be a git repository with /usr in .gitingore.

When updates are done, you would run etc-update on the build host by
committing the changes to / into git with ./usr in .gitignore. Then you
would have the delta from /usr via whatever mechanism that the user
wishes to use with a patch on / from the build system that can be merged
into each target's / repository. The procedure would require more effort
than what Solaris and RHEL do, but if documented, it should fix the
partial update problem that occurs when you do a /usr merge in a rolling
release and then do what people on Solaris and RHEL do to update systems
configured for updates via deltas of /usr.

To give an example, lets assume:

1. /path/to/build/image has a git repository with ./usr in .gitignore on
the build host while the targets have the same (with paths being / and
/usr of course).

2. Things are on ZFS on the build host and the targets.

3. There is a snapshot of the build environment that the targets have.

4. tank/BUILD/gentoo is the / and tank/BUILD/gentoo/usr is the /usr on
the build host.

5. The targets have rpool/SYSTEM/USR/gentoo as their /usr and
rpool/SYSTEM/USR is set readonly (so /usr is not modified due to
inheritance of readonly).

The delta generation would be something like this:

# Setup build environment
sudo -i /path/to/enter-container.sh /path/to/build/image
https://gist.github.com/ryao/3c345f206b19c9795109)

# Update portage
emerge-webrsync / emerge-delta-webrsync / emerge --sync
# Preferably one of the first two with PORTAGE_GPG_* configured

# Install updates
emerge -avDuN @world

# Update config files
etc-update

# Exit build environment
exit

# Commit changes to /
git -C /path/to/build/image commit -a

# Snapshot the build environment
sudo -i zfs snapshot -r tank/BUILD/gentoo@"$(date +%Y%m%d)"

Then a child could be updated by something like:

# First /usr
zfs send -i tank/BUILD/gentoo@previous tank/BUILD/gentoo/usr@"$(date
+%Y%m%d)" | ssh root@$CHILD zfs recv rpool/SYSTEM/USR/gentoo

# Then /
git -C /path/to/build/image diff HEAD^ | ssh root@$CHILD git -C
/other/location apply

# If conflicts occurred, fix whatever was broken
ssh root@$CHILD

# Reboot / restart services
reboot

This is intended to only be an example, but there are a few problems
with this simple example that are worth mentioning:

1. You probably want to have a shell into the system in case the update
to / does not go well, which makes the update to / somewhat hackish.

2. The way Solaris does things is to have boot environments where the
change is in a different boot environment that only takes effect as part
of a reboot. If you are doing a boot environment type thing, you could
probably update / for the new reboot, although you would want to
implement easy rollback if anything goes wrong.

That step on / is somewhat hackish, but it is intended to be an example.

Doing something similar to what Solaris did to make management of
multiple systems easier is likely doable with some way of handling
changes outside of /usr.

> I do not understand how CONFIG_PROTECT is relevant here. 

Re: [gentoo-dev] usr merge

[waltdnes]

On Wed, Apr 06, 2016 at 12:15:58AM -0400, Richard Yao wrote


> If others are not willing to be advocates for ***THOSE USERS THAT WOULD
> ONLY MAKE THEMSELVES KNOWN AFTER AN A FUNDAMENTAL CHANGE HAS BEEN MADE
> AND PEOPLE ARE DETERMINED TO GO AHEAD WITH THIS***, I suggest having
> and testing a plan for backing out the change should the backlash
> from users after systems break be more than people can stomach. This
> is not the sort of change we should make without an "exit strategy".

  The problem is that those end users didn't know about it until it they
read the news item during an emerge.  That is why they "would only make
themselves known after a fundamental change has been made".  There are a
couple of alternatives...

a) tell all end-users that they should regularly monitor this list.  The
disadvantage is that you probably don't want to be flooded with
questions from newbies on this list.

b) ask on the Gentoo-user mailing list... ***BEFORE MAKING A DECISION
AND INVESTING ANY WORK IN A MAJOR CHANGE***

  Otherwise, you end up with a scenario similar to the following "fair
use" snippett from "The Hitch Hiker's Guide To The Galaxy" series...



ARTHUR DENT:
Didn't anyone consider the alternatives?

MISTER PROSSER:
There aren't any alternatives! But you are quite entitled to make any
suggestions or protests at the appropriate time!

ARTHUR DENT:
Appropriate time?

MISTER PROSSER:
Yes.

ARTHUR DENT:
The first I knew about it was when a workmen arrived at the door
yesterday.

MISTER PROSSER:
T- oh!

ARTHUR DENT:
I asked him if he'd come to clean the windows and he said he'd come to
demolish the house! He didn't tell me straight away of course. Oh no.
First he wiped a couple of windows and charged me a fiver. Then he told
me.

MISTER PROSSER:
But Mister Dent the plans have been available in the planning office for
the last nine months!

ARTHUR DENT:
Yes! I went round to find them yesterday afternoon. You'd hadn't exactly
gone out of your way to pull much attention to them have you? I mean,
like actually telling anybody or anything.

MISTER PROSSER:
The plans were on display.

ARTHUR DENT:
Ah! And how many members of the public are in the habit of casually
dropping around the local planning office of an evening?

MISTER PROSSER:
Er - ah! 

ARTHUR DENT:
It's not exactly a noted social venue is it? And even if you had popped
in on the off chance that some raving bureaucrat wanted to knock your
house down, the plans weren't immediately obvious to the eye were they?

MISTER PROSSER:
That depends where you were looking.

ARTHUR DENT:
I eventually had to go down to the cellar!

MISTER PROSSER:
That's the display department.

ARTHUR DENT:
With a torch!

MISTER PROSSER:
The lights, had# probably gone.

ARTHUR DENT:
So had the stairs!

MISTER PROSSER:
Well you found the notice didn't you?

ARTHUR DENT:
Yes. It was on display in the bottom of a locked filing cabinet, stuck
in a disused lavatory with a sign on the door saying "Beware of the
Leopard". Ever thought of going into advertising? 

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] usr merge

[Alexis Ballier]

On Wednesday, April 6, 2016 6:57:20 PM CEST, Alexis Ballier wrote:
usr-merge does not deal with that at all. usr-merge deals with 
the intracate dependencies of /usr onto /lib, /bin, etc. by 


now that I read this again: 'etc.' was the shortcut for 'et caetera' and 
has nothing to do with /etc in this sentence

Re: [gentoo-dev] usr merge

[Alexis Ballier]

On Wednesday, April 6, 2016 6:33:41 PM CEST, Richard Yao wrote:

On 04/06/2016 12:20 PM, Alexis Ballier wrote:

On Wednesday, April 6, 2016 6:06:35 PM CEST, Richard Yao wrote:
 ...


Leveraging the /usr merge to enable easier updating of multiple systems
means that you are updating a Gentoo system image on a build server,
snapshotting /usr both before/after the update and then distributing the
delta on /usr to other systems without any of the changes that occurred
outside of /usr. A proper update requires finding all of those changes
and then applying them manually. That really is not the same thing that
RHEL and Solaris have, where the necessity of propagating changes
outside of /usr is minimized by having none to propagate.

I do not understand how CONFIG_PROTECT is relevant here. Whatever
CONFIG_PROTECT did was done on the build system. The systems receiving
the updates via ZFS send/recv or some similar mechanism are not going to
have CONFIG_PROTECT evaluated. Even if it were somehow evaluated, all of
the paths in CONFIG_PROTECT should be outside of /usr anyway.


Exactly. CONFIG_PROTECT requires admins to (sort of) manually merge /etc 
changes. If you want all changes on the build server to be magically 
propagated to clients, then share it over nfs or whatever is your prefered 
mechanism. This is not a great idea though, FHS is quite clear on the 
matter: /etc : Host-specific system configuration


usr-merge does not deal with that at all. usr-merge deals with the 
intracate dependencies of /usr onto /lib, /bin, etc. by simply removing 
them. If you want to share everything, then use nfsroot and mount local 
disks by label.

Re: [gentoo-dev] usr merge

[Richard Yao]

On 04/06/2016 12:20 PM, Alexis Ballier wrote:
> On Wednesday, April 6, 2016 6:06:35 PM CEST, Richard Yao wrote:
> 
>> That is unless you put per-system state in /usr/local, do symlinks to it
>> in / and mount /usr/local as part of system boot, which is the other way
>> of doing this. I have seen a variant of this done in asuswrt-merlin on
>> routers.
> 
> This doesnt seem to have anything to do with what I was describing.
> 
> Another option I'm using a lot is nfsroot. This doesn't have the same
> level of flexibility: running multiple hosts with nfsroot and thus
> shared /etc/fstab tends to be annoying.
> 
>>> See https://fedoraproject.org/wiki/Features/UsrMove for a more complete
>>> discussion.
>>
>> That does not address the problems of supporting this configuration in a
>> rolling release.
>>
>> Formats in /etc can fall out of sync with software in /usr. If boot
>> options change, the stuff in /etc/init.d is not updated. If you add
>> software, the update to /etc/init.d is omitted. If you have a baselayout
>> change, it is not propagated.
> 
> Ever heard of CONFIG_PROTECT ? :) What you describe is already what
> happens and what most people want.

Leveraging the /usr merge to enable easier updating of multiple systems
means that you are updating a Gentoo system image on a build server,
snapshotting /usr both before/after the update and then distributing the
delta on /usr to other systems without any of the changes that occurred
outside of /usr. A proper update requires finding all of those changes
and then applying them manually. That really is not the same thing that
RHEL and Solaris have, where the necessity of propagating changes
outside of /usr is minimized by having none to propagate.

I do not understand how CONFIG_PROTECT is relevant here. Whatever
CONFIG_PROTECT did was done on the build system. The systems receiving
the updates via ZFS send/recv or some similar mechanism are not going to
have CONFIG_PROTECT evaluated. Even if it were somehow evaluated, all of
the paths in CONFIG_PROTECT should be outside of /usr anyway.

Re: [gentoo-dev] usr merge

[Richard Yao]

On 04/06/2016 12:06 PM, Richard Yao wrote:
> On 04/06/2016 11:11 AM, Alexis Ballier wrote:
>> On Wednesday, April 6, 2016 4:58:05 PM CEST, M. J. Everitt wrote:
>>> What, if any, is the benefit of squashing /usr out of the equation? I
>>> happen to have a few workstations that load their /usr off an NFS share
>>> presently,
>>
>>
>> This is precisely one case where I see benefits: no need to correlate /
>> and /usr.
>>
>> With the current way, this setup is broken if you don't pay attention:
>> glibc is not backwards compatible (that is, stuff built for glibc 2.22
>> is not guaranteed to work with 2.21 and less), but you have glibc in
>> /lib and stuff in /usr linking and dynamically loading it. If your nfs
>> server updates glibc, you have to update every / on every of your
>> workstations or fear the consequences of running binaries built for 2.22
>> but running against an older version.
>>
> 
> That is unless you put per-system state in /usr/local, do symlinks to it
> in / and mount /usr/local as part of system boot, which is the other way
> of doing this. I have seen a variant of this done in asuswrt-merlin on
> routers.
> 
>> See https://fedoraproject.org/wiki/Features/UsrMove for a more complete
>> discussion.
> 
> That does not address the problems of supporting this configuration in a
> rolling release.
> 
> Formats in /etc can fall out of sync with software in /usr. If boot
> options change, the stuff in /etc/init.d is not updated. If you add
> software, the update to /etc/init.d is omitted. If you have a baselayout
> change, it is not propagated. Whether or not the package manager can be
> used is not discussed. It definitely can be in Solaris when this feature
> is used in Solaris zones, although I am not sure how that interacts with
> updates as I never looked. I do not have a VM with a member of the
> OpenSolaris family handy to check.
> 
> Solaris and RHEL will see the benefits described on the Fedora page
> because they handled many of those problems. In most cases, they handled
> it by being stale non-rolling releases that do not support major version
> upgrades. Fedora handled it by having a disclaimer that things should be
> expected to break across Fedora versions. Neither are things that I
> expect us to do, so if we adopt this, we will need to do something
> entirely new to be able to gain these benefits.

To say it clearly, lets not claim that the /usr merge will give us any
of the benefits mentioned in the Fedora wiki unless we have a plan to
handle the complications that being a rolling distribution poses for
doing atomic updates via the mechanism invented in Solaris on a
post-/usr merge system.

On a non-rolling system release like Solaris or RHEL, you  need to
install information on how to boot daemons with default configurations
in /usr and let users override things in /etc in addition to the /usr
merge to gain the capabilities cited on the Fedora wiki page. You get
bonus points if a clone of a snapshot can be used to make a container
with a working package manager, but could otherwise define that
configuration as being unsupported or write a script to install it.

On a rolling release like Gentoo, rearranging the system baselayout is
also insufficient, but there are many more problems than those that
occur on a non-rolling system release. I listed most of those in my
previous email.

Re: [gentoo-dev] usr merge

[Alexis Ballier]

On Wednesday, April 6, 2016 6:06:35 PM CEST, Richard Yao wrote:


That is unless you put per-system state in /usr/local, do symlinks to it
in / and mount /usr/local as part of system boot, which is the other way
of doing this. I have seen a variant of this done in asuswrt-merlin on
routers.


This doesnt seem to have anything to do with what I was describing.

Another option I'm using a lot is nfsroot. This doesn't have the same level 
of flexibility: running multiple hosts with nfsroot and thus shared 
/etc/fstab tends to be annoying.



See https://fedoraproject.org/wiki/Features/UsrMove for a more complete
discussion.


That does not address the problems of supporting this configuration in a
rolling release.

Formats in /etc can fall out of sync with software in /usr. If boot
options change, the stuff in /etc/init.d is not updated. If you add
software, the update to /etc/init.d is omitted. If you have a baselayout
change, it is not propagated.


Ever heard of CONFIG_PROTECT ? :) What you describe is already what happens 
and what most people want.