On Thu, 7 Nov 2019 20:40:40 +0000 Sergei Trofimovich <sly...@gentoo.org> wrote:
> On Thu, 7 Nov 2019 11:52:19 -0800 > Patrick McLean <chutz...@gentoo.org> 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 > >