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

[Sergei Trofimovich]

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?

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?

> 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 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.

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


-- 

  Sergei