Discussion and tracking bug for merged usr problems and solutions
dumping some info from IRC discussion: <@floppym> Someone wrote a script to migrate Gentoo systems to merged-/usr. Does anyone remember where that is? <@gyakovlev> floppym: https://github.com/dracutdevs/dracut/blob/master/modules.d/30convertfs/convertfs.sh <@gyakovlev> dracut actuall has this =) <@gyakovlev> I think fedora used it to migrate existing systems in an early phase where root is mounted but not pivoted to. <@gyakovlev> but ofc it would not work for gentoo <@gyakovlev> with the amounts of custom stuff users do to their systems. <@floppym> gyakovlev: Thanks! <+sam_> oh nice!! <@floppym> I'm really tempted to require merged-/usr to run systemd on Gentoo within the next couple of releases. <@floppym> So I will probably start working on new set of systemd profiles. <@gyakovlev> I've been running that kind of system for a long time so far. <@gyakovlev> it's mostly ok. <@gyakovlev> kernel eclasses are still broken tho <@floppym> How so? <+sam_> I migrated my system on the weekend and it's been fine so far <@gyakovlev> those create incorrect symlink <@gyakovlev> /usr/lib/modules/<>/build <@floppym> Hmm. <@gyakovlev> points to incorrect number of ../../src/linux <@gyakovlev> so you can't build 3rd party modules <+sam_> sounds easy to fix <@gyakovlev> sam_: well maybe, but I got tried of hunting this <@floppym> Well, relative symlinks don't play well with directory symlinks. <@gyakovlev> something somethere uses realpath <@gyakovlev> so it resolves with /usr part <+sam_> interestingly I didn't hit this with zfs when I upgraded kernel yday <@gyakovlev> but expects /lib/modules path <@gyakovlev> zfs is smarter =) <@floppym> /lib/modules/x/build and /usr/lib/modules/x/build cannot possibly point the same place with a relative symlink. <@gyakovlev> that one is not affected <@gyakovlev> pure KBUILD packages are affected <+sam_> ahhh <@gyakovlev> maybe doing absolute symlink is a solution? <@gyakovlev> idk <@floppym> Yes, unfortunately I think that's the only reliable solution. <@floppym> And it doesn't work if SYSROOT != / <@floppym> I'm not sure how much of the kenrnel ebuild infra works when cross-compiling anyway. <@gyakovlev> ok I'm starting to remember (sorry just had coffee) <@gyakovlev> I think only dist-kernels are broken <@gyakovlev> because those assume /lib <@gyakovlev> and install incorrect relative symlink <@gyakovlev> I think make_install style gentoo-sources resolve fine. <@gyakovlev> rwxrwxrwx 1 root root 38 Apr 26 17:00 source -> ../../../usr/src/linux-5.15.35-talos64 <@gyakovlev> ^ that is broken symlink if viewed from /lib/modules/5.15.35-talos64 <@gyakovlev> and is broken from /usr/lib/modules/5.15.35-talos64 <+sam_> weird <+sam_> ah I see it now <+sam_> lrwxrwxrwx 1 root root 51 May 9 19:32 build -> ../../../usr/src/linux-5.15.38-gentoo-dist-hardened <+sam_> lrwxrwxrwx 1 root root 51 May 9 19:32 source -> ../../../usr/src/linux-5.15.38-gentoo-dist-hardened <@gyakovlev> yeah it should have either extra ../ <@gyakovlev> or no usr/ part <@gyakovlev> I think we talked about this before and agreed that split-usr for dist-kernels is most obvious solution <@gyakovlev> the flag I mean <@floppym> Another possible solution would be to create a symlink /src -> usr/src. -*- gyakovlev hears FHS crowd wooo-ing <@floppym> Then a relative symlink ../../src/linux would work from either location. <+sam_> I'd prefer USE=split-usr or something I think. <@gyakovlev> split-usr is most obvious and discoverable way indeed. <@gyakovlev> or some autodetection magic <@floppym> Autodetection magic is bad. <@floppym> Would much rather utilize the USE flag. <@gyakovlev> yeah it exists for a reason and hundreds of packages use it <@gyakovlev> I'm still in semi-amoeba mode but will try to handle it from dist-kernel side <@gyakovlev> just keep in mind this before new profiles, that'd be a blocker =) <@gyakovlev> btw I also built merged usr stages locally <+sam_> oh nice <@gyakovlev> works fine <+sam_> i think jpds hit some issues with doing that <+sam_> do speak to him but should be fixable <@gyakovlev> another thing: <@gyakovlev> UNINSTALL_IGNORE="${UNINSTALL_IGNORE} /bin /sbin /usr/sbin /lib /lib64" <@gyakovlev> this is needed in make.conf (or profiles) <@gyakovlev> otherwise portage would be bitching about symlinks <@gyakovlev> also some compressors (pigz lbzip2) have USE=symlink flag <@gyakovlev> this will have to be masked <@gyakovlev> those make symlink in usr like pigz -> gzip <@gyakovlev> since /usr/bin comes 1st in order in path it uses pigz by default <@gyakovlev> but it will not work for merged usr ofc
merged-usr profiles have been added.
