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

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

[Patrick McLean]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

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.


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

[-- Attachment #2: libcrypt-0.ebuild --]
[-- Type: application/octet-stream, Size: 640 bytes --]

# Copyright 1999-2019 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

EAPI=7

DESCRIPTION="Virtual for libcrypt.so"

SLOT="0"
KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 ~riscv s390 sh sparc x86 ~ppc-aix ~x64-cygwin ~x86-cygwin ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~m68k-mint ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris"

DEPEND="
	elibc_glibc? ( || (
			sys-libs/glibc[crypt(+)]
			sys-libs/libxcrypt[system(-)]
		)
	)
	elibc_musl? ( sys-libs/musl )
	elibc_uclibc? ( sys-libs/uclibc-ng )
	elibc_Cygwin? ( sys-libs/cygwin-crypt )
"
RDEPEND="${DEPEND}"

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]

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?

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

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

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

[Sergei Trofimovich]

On Thu, 7 Nov 2019 11:52:19 -0800
Patrick McLean <chutzpah@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?

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

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

[Patrick McLean]

On Thu, 07 Nov 2019 21:28:34 +0100
Michał Górny <mgorny@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  
> 

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

[Patrick McLean]

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

> On Thu, 7 Nov 2019 11:52:19 -0800
> Patrick McLean <chutzpah@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  
> 
> 

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

[Zac Medico]

[-- Attachment #1.1: Type: text/plain, Size: 287 bytes --]

On 11/7/19 11:52 AM, Patrick McLean wrote:
> DEPEND="
> 	elibc_glibc? ( || (
> 			sys-libs/glibc[crypt(+)]

If a new version of glibc will remove crypt then it needs to be
something like:

|| ( >=sys-libs/glibc-2.30-r2[crypt(-)] <sys-libs/glibc-2.30-r2 )

-- 
Thanks,
Zac


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

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

[Patrick McLean]

[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]

On Thu, 7 Nov 2019 11:52:19 -0800
Patrick McLean <chutzpah@gentoo.org> wrote:

I will push the attached version with zmedico's change on Friday unless
there are objections (I have addressed all the feedback so far AFAIK).

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


[-- Attachment #2: libcrypt-0.ebuild --]
[-- Type: application/octet-stream, Size: 692 bytes --]

# Copyright 1999-2019 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

EAPI=7

DESCRIPTION="Virtual for libcrypt.so"

SLOT="0"
KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 ~riscv s390 sh sparc x86 ~ppc-aix ~x64-cygwin ~x86-cygwin ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~m68k-mint ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris"

DEPEND="
	elibc_glibc? ( || (
			|| (
				<sys-libs/glibc-2.30-r2
				>=sys-libs/glibc-2.30-r2[crypt(-)]
			)
			sys-libs/libxcrypt[system(-)]
		)
	)
	elibc_musl? ( sys-libs/musl )
	elibc_uclibc? ( sys-libs/uclibc-ng )
	elibc_Cygwin? ( sys-libs/cygwin-crypt )
"
RDEPEND="${DEPEND}"