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 noooo, 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
kumba@g.o
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