Michał Górny posted on Wed, 20 Dec 2017 14:40:27 +0100 as excerpted:

> A new set of 17.1 amd64 profiles has been added to the Gentoo
> repository. Those profiles switch to a more standard 'no SYMLINK_LIB'
> multilib layout,
> and require explicit migration as described below. They are considered
> experimental at the moment, and have a fair risk of breaking your
> system. We would therefore like to ask our users to test them on their
> non-production ~amd64 systems.
> 
> In those profiles, the lib->lib64 compatibility symlink is removed.
> The 'lib' directory becomes a separate directory, that is used for
> cross-arch and native non-library packages (gcc, clang) and 32-bit
> libraries on the multilib profile (for better compatibility with
> prebuilt x86 packages).


In all this I don't see an answer to one question:

Will this eventually be the only supported choice, or is the 
compatibility-symlinked version going to be supported going forward too?  
If it's to be only-supported, what's the timeline?


Here's why I'm asking:  I'm on nomultilib and already have usrmerge (tho 
reverse, with / being canonical and /usr -> .), and (s)bin merge, so I 
already have a single canonical /bin and a single canonical /lib64, with 
various symlinks making the other paths work as well.

So there's no reason or benefit to me splitting /lib and /lib64 again, as 
that would go against the concept of the usr and sbin merges I've already 
done, and the long-time lib merges that gentoo has had on amd64 since 
before I switched to gentoo in 2004.  I've found I quite /like/ having a 
single bin dir and a single lib dir for everything, and this would undo 
that, forcing me to mentally track separate lib locations once again.


So I'll probably keep my merged lib here, managing it much like I do my 
merged bin and root/usr, but it'd be nice to know whether that's going to 
remain an official layout or not, and if not, what the timeframe for 
removing it is.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply via email to