Gentoo Archives: gentoo-dev

From: Patrick McLean <chutzpah@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] rfc: virtual/libcrypt for libcrypt.so implementation
Date: Thu, 07 Nov 2019 21:36:59
Message-Id: 20191107133652.09c61426@patrickm.gaikai.org
In Reply to: Re: [gentoo-dev] rfc: virtual/libcrypt for libcrypt.so implementation by Sergei Trofimovich
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.