Re: [gentoo-dev] usr merge

[Alexis Ballier]

On Tuesday, April 5, 2016 3:19:59 AM CEST, William Hubbs wrote:
[...]
> 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

(OT: maybe it'd be a good oportunity to kill SYMLINK_LIB too :p)

> /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 think that prior to that we have to ensure that packages with intra 
collisions are not merged: What happens with current coreutils ebuilds that 
install, e.g., /bin/seq and a /usr/bin/seq symlink to it ?
I haven't looked at the actual code, thus I can only assume there are no 
guarantees, which is definitely bad.


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


Does it behave properly wrt portage's way of tracking of package files? I 
remember that modifying files owned by portage used to cause issues.

What should baselayout ebuild do on systems that have not run that script ?

Also, I think your script may not work:

# copy binaries
for dir in /bin /sbin /usr/sbin; do
	run_command cp -a $dir/* /usr/bin
done

---> Here it is important to ensure nothing /usr/bin/ is a symlink to /bin, 
otherwise this would just copy, e.g., /bin/seq onto /bin/seq


# Create the /usr merge compatibility symlinks
for dir in /bin /sbin; do
run_command rm -rf $dir

---> where are the 'ln' and 'rm' taken from after this step ?
If this fails here, you're also leaving the system in a broken state.

run_command ln -s usr/bin $dir
done