Re: [gentoo-dev] rfc: virtual/libcrypt for libcrypt.so implementation

[Patrick McLean]

On Thu, 7 Nov 2019 20:40:40 +0000
Sergei Trofimovich <slyfox@g.o> wrote:

> On Thu, 7 Nov 2019 11:52:19 -0800
> Patrick McLean <chutzpah@g.o> 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.
>
> It's not clear how this virtual is supposed to work when
> sys-libs/libxcrypt actually changes ABI. Do we care about the missing
> rebuilds or we do not?

I clarified this in a reply to mgorny's message.

>
> If we don't it's (not ideal but) fine. But it should be stated
> explicitly and consequences should be described: does
> sys-libs/libxcrypt override glibc's libcrypt.so.1 and break existing
> applications? Or we guarantee it not to happen?
>
> >	elibc_glibc? ( || (
> >			sys-libs/glibc[crypt(+)]
> >			sys-libs/libxcrypt[system(-)]
> >		)
> >	)
>
> Same for switching providers back and forth. For example, should we
> allow user to come back from sys-libs/libxcrypt to sys-libs/glibc?

With the current dual-library approach, switching back and fourth is
possible, but may involve a preserved-libs rebuild of recently built
packages. Portage does detect this and handle it cleanly.

>
> > 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.
>
> I don't think tinderbox will find much as util-linux, shadow or any
> other low-level package will pull it in as a dependency and be
> silently available.

I suppose that is true, though we could detect via the NEEDED* files
that portage generates in the vdb (we just need _all_ packages to be
installed somewhere at some point to detect it).

>
> I think you'll need to do extra to find those. Like, removing
> libcrypt.so to make sure linker won't find it even if libcrypt.so.1
> is available.

That is another approach, we could do some hackery in the tinderbox
once the basic system packages are there so we can detect those.

>
> > [1]
> > https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;h=50479f17c9a3a5ef074dafa3f23aca954b82bd6a;hb=HEAD#l768
> > [2] https://bugs.gentoo.org/699422
>
>