Re: [gentoo-user] Re: USE flag 'split-usr' is now global

[Grant Taylor <gtaylor@gentoo.tnetconsulting.net>]

On 8/5/19 5:34 PM, Mick wrote:
> I am not entertaining ad hominem attacks on whoever may have been 
> involved in such decisions.  Only the impacts of such decisions on 
> gentoo in particular.

:-)

> I probably used an incorrect figure of speech and caused confusion. 
> We're only discussing the merge of /bin and /sbin to /usr/bin and 
> /usr/sbin (it seems to be more nuanced than this though - see gentoo 
> forums thread further down).

I started to read to be able to be informed when drafting my reply. 
Emphasis on "started".  The first comment to the quote makes me think 
that it's going to be a lively discussion.  I'll read it later as time 
permits and respond accordingly.

> However, the takeover of Linux in general by systemd architectural 
> changes is a fact.  It is also a fact gentoo has been changed a lot 
> to accommodate systemd.  I have set USE="-systemd" but still end 
> up with service unit files on my system, unless I take additional 
> steps to remove/mask them.  At some point udev/dbus/what-ever will be 
> irrevocably linked to systemd, just because its devs do not care for 
> alternative architectures.  Some packages require systemd components, 
> like (e)logind, and so on.  Some years ago eudev was forked from 
> systemd with a stated aim at the time to also restore the borked 
> separate /usr without an initrd - did this ever happen?  There is 
> a direction of travel and it has been influenced heavily by systemd 
> design decisions.

ACK

I think I could draw analogies with XFree86 vs Xorg vs Wayland.  In the 
beginning, nobody wants to actively stop development of the old method. 
But in the end, nobody wants to devote any effort to keep bring the old 
method forward.  Thus the old method gets left behind.

I'm not saying it's correct, or not, just that it is the nature of things.

> There isn't any - I haven't seen it either.  Sorry if I confused 
> the point.

Actually, the quote in the first forum post you linked to has the following:

/sbin->usr/bin
/usr/sbin->bin

That takes four directories (/bin, /sbin, /usr/bin, /usr/sbin) and 
combines them into two (/sbin & /usr/bin and /bin & /usr/sbin) but it 
also crosses bin & sbin as well as going opposite directions with the 
links.  —  Yuck!!!

> Yes, same here, but this is primarily because since gentoo's change in 
> this area I moved away from using a separate /usr fs to avoid having 
> to use an initrd.

ACK

> I have given one benefit of keeping a separate fs for /usr, mounting 
> it read only for daily use.  Or you could have a shared NFS partition 
> across various client PCs, facilitating system duplication.  You could 
> also have /usr on a faster disk for performance reasons.

ACK

> A benefit of /var being separate (or wherever www/, logs/, mail/ 
> and databases are stored) is so that if it runs out of space the 
> remaining system is not brought to its knees.

ACK


> Ditto for /home, with the addition of encrypting user's data/partition 
> and mounting it with nosetuid (to prevent the users from running 
> their own secret root shell).

ACK

> So at least two reasons, helping to manage (simply) access rights and 
> space are valid enough reasons IMHO to not remove a separate /usr 
> option from gentoo, but I'm interested to hear what others think.

Agreed..

> One might argue you still retain the option of using a separate /usr, 
> but with the new added restriction of being obliged to engage in 
> boot time gymnastics with an initrd, LVM, your mount-bind solution 
> and whatever else.

I don't have any current first hand experience with /usr being a 
separate file system without using an initramfs / initrd.  So I'm going 
to have to take what you, and others, say on faith that it can't 
/currently/ be done.  But I've got to say, that I find that idea 
disturbing and highly suspicious.

I'd be curious for pointers to bugs about this if you have them handy. 
Please don't look, I'll dig later if I'm sufficiently motivated.

> However, workarounds which add complication (remove simplicity and 
> flexibility) to fix something after breaking it, is what all this 
> argument is about.  Such changes remove choice.

Ya.  It's sort of like painting yourself into a corner because one (or 
more) too many bad decisions were made in the past.  I'd much rather 
admit that a bad decision was made, undo it, and move forward again with 
new knowledge.  Sadly, IMHO not enough people do that.

> I'll try not to mess up the thread.  :-)

:-D

I'll try as well.  But I'm betting that we're both human.

> Please do, the systemd merge refers merging /bin to /usr/bin and 
> /sbin to / usr/sbin.
> 
> https://fedoraproject.org/wiki/Features/UsrMove
> 
> However, this gentoo thread mentions further merging, which made my 
> head spin:
> 
> https://forums.gentoo.org/viewtopic-p-7902764.html

Ya.  I need to read that thread in detail.

The following bit concerns me.  I do hope that it's a typo.

/sbin->usr/bin
/usr/sbin->bin

> You're probably correct.  In any case, the initial move of 
> subdirectories of the / fs to different physical disks and hence 
> different fs' was for storage space reasons.

Agreed.

> Yes, for plain users.

I think it's for /all/ users, not just plain (non-root) users, because 
root will also want commands in /bin & /usr/bin for various things.

I think of it more as non-root users don't /need/ the contents of /sbin 
& /usr/sbin for the vast majority of what they do.

> OK, I'll rephrase this.  Certain binaries require corresponding libs 
> to be accessible at the same time and /libs under /usr mushroomed to 
> allow a separate /usr partition to function.

Agreed.

> You are right, they just require to be accessible at the same time, 
> which during boot time when some fs are not yet mounted (e.g. /usr) 
> could cause breakage.

Yep.

I have historically considered what's on the / (root) file system to be 
what's required to boot-strap the system.  Once the system has been 
booted, then all typical file systems are accessible.

> It is secondarily important today, although at the time disk space 
> was the primary reason for migrating fs away from / partition.

Okay.  That makes more sense.  Thank you for clarifying.

> What I was trying to say is, today storage space is usually a smaller 
> and cheaper problem than it was at the early stages of UNIX and 
> therefore *today* it is likely different purposes could be listed as 
> having a higher priority for requiring different fs' to be deployed.

Fair enough.

> Discovering my flexible gentoo system won't boot without an initrd, 
> just because binary distros use initrd by default, should not be the 
> logic for limiting architectural choices, on gentoo.  We should pause, 
> discuss and (hopefully) agree.

Agreed.

> The Gentoo Trustees should do just that, i.e. ensure the project 
> follows the Gentoo way.  No.1 Gentoo Principle:
> 
> "Gentoo provides choices."
> 
> https://wiki.gentoo.org/wiki/Foundation:Main_Page
> 
> If some dev, i.e. a gentoo community member who is contributing code, 
> limits choices for users, then it follows his/her code does not fit 
> into Gentoo and therefore Gentoo *should* not adopt it.

I feel like there is an important distinction between what you have now 
said and what I meant with what you quoted.

IMHO there is a big difference in the Gentoo community deciding (through 
due process) that the community does not want to include the developers 
code into the base portage.

Conversely, I was originally meaning something along the lines of "you 
don't follow the Gentoo methodology, therefore you are forbidden from 
even applying to the community for inclusion."

> If s/he is a project lead and pushes changes against the Principles, 
> then technical decisions on such matters can be taken by the Gentoo 
> Council, but it is ultimately down to the Trustees to straighten 
> out deviations from the Gentoo Principles.

Oy vey!

> I've written this as if it is black and white, but of course there 
> are various shades of grey in- between.

*nod*nod*

> Either way, making one wrong decision at at time could end up with 
> Gentoo gradually mutating into a systemd solution, which has already 
> restricted choice (udev -> usr -> initrd).

I don't want to agree, but your logic is correct.

> I did not mean it this way.  Code is gratefully received, but let's 
> not change Gentoo because any code was received.  The shoe has to 
> fit the foot.

Agreed.

Sometimes that means taking 95% of the code and modifying 5% of it to 
fit the Gentoo methodology.  ;-)

> Because RHL devs have particular use cases in mind.  For them /usr 
> on a separate fs without an initrd is a "custom setup".

Yet RHEL has Kickstart and many different ways to automate such "custom 
setups".

Has RHEL gotten /that/ short sighted that they think there are no longer 
people that do anything but click next a bunch of times and accepting 
the default?

*HEAVYsigh*

Nevermind.  Don't answer that.

> Sure.  Investigating opportunities to improve Linux is laudable.

Very well said.

> Right, until udev won't work without /usr being mounted and then an 
> initrd is a must.

I need to do some research.

> Yes, until we started deviating from it, because someone offered 
> us code.

Is any distro following FHS even remotely faithfully any more?  I 
thought most mainstream distros had moved on about ten years ago.

> Gentoo is by principle more accommodative than binary distributions 
> and I'd rather it remained so.

ACK

> Agreed.  I'm not advocating stifling discussion or innovation.

:-)

> Right, which is rather different from:
> 
> We've outsourced code development to RHL devs and we'll use whatever 
> they feed us, even if this changes our OS to a disagreeable degree.

:-/

> At the same time I know devs are a scarce resource and good devs 
> even scarcer, so there will always be a need to avoid reinventing 
> the wheel and use what upstream provide.  I just hope the Gentoo 
> principles hold a while longer.

Maybe it's my Slackware roots showing.  But I want to believe that it's 
possible to judiciously configure and compile software to work on just 
about any platform.  (Assuming that the requisite version of libraries 
are somewhere on the system.)



-- 
Grant. . . .
unix || die