On Thu, 07 Nov 2019 21:28:34 +0100
Michał Górny <mgo...@gentoo.org> wrote:
> On Thu, 2019-11-07 at 11:52 -0800, Patrick McLean wrote:
> > Given glibc upstream's tentative plans to remove libcrypt [1], I
> > think we should start working out the kinks well in advance.
> > Toolchain has already added a package.use.force-ed "crypt" USE flag
> > to sys-libs/glibc-2.30-r2 [2]. The main alternative out there is
> > libxcrypt, which I have recently bumped and added a
> > package.use.mask-ed "system" USE flag to make it provide the
> > "system" version of libcrypt.so.
> >
> > To give us time to work out dependencies in advance, I would like to
> > propose a virtual to provide libcrypt.so, and we can gradually
> > update all users of libcrypt to {R,}DEPEND on this virtual.
> >
> > Maybe once this is in place and the obvious/common packages are
> > updated, we could request a tinderbox run to flush out what was
> > missed.
>
> Are you planning to use backwards-compatible .so.1 version of
> libxcrypt, or do you plan to switch to .so.2?
The current plan would be to initially we would be install both a .so.1
with full ABI compatibility with glibc (libxcrypt supports this) and a
.so.2 that libcrypt.so symlinks to without glibc compatibility (with
USE="compat" this is the current behaviour of the ebuild). Current
packages are using the .so.1 and any new builds end up linking to the
.so.2.
Eventually we can turn off the "compat" USE flag by default, some users
might end up doing preserved-libs rebuilds, but hopefully by that time
most stuff will be using .so.2.
> >
> >
> > [1]
> > https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;h=50479f17c9a3a5ef074dafa3f23aca954b82bd6a;hb=HEAD#l768
> > [2] https://bugs.gentoo.org/699422
>
