* "Andreas K. Huettel" <2862978.mvXUDI8C0e @pinacolada> : Wrote on Sun, 07 Apr 2024 15:27:42 +0200:
>> I see no way of migrating to 23.0 profile because of not-recompilable >> packages that are installed (over 4 years) which block --emptytree, >> and do not wish to be forced to migrate to merged-usr on an openrc box >> without a compelling need (on principle). > That sounds a bit like self-inflicted pain. >> Will patching back the 17.0 profile files into the portage tree if and >> when they are removed work? > Unknown. > >> Are there any options at all for this situation (like freezing the the >> last supported tree protecting it from emerge-syncs, and using an >> overlay for further updates?) > > You can try to just skip these packages (with --exclude) during the > "emerge --emptytree ..." step. It should work, but no guarantees given. I switched the make.conf symlink (from portage/profiles/default/linux/amd64/17.1 to portage/profiles/default/linux/amd64/23.0/split-usr ) and the only difference in the emerge --info output is that LDFLAGS now additionally has "-Wl,-z,pack-relative-relocs" My use pattern is I'm only emerging packages by hand and setting useflags on a case by case basis. Also I have binpkgs going back to 5 years that I don't want to lose (by going to merged-usr, right now I can unpack and test these in a pinch). I also have various other packages outside the gentoo tree which depend on stuff which is not in gentoo portage anymore, which are really not rebuildable, but because of past portage flexibility multiple installed work fine and can be tested at the same time. The question is: Now if I don't attempt to do a rebuild and just update libtool and do further upgrades and installs on a case by case basis, it will will eventually pick up the new profile defaults. Is there any foreseeable downside to just doing this?
