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
