Project:Toolchain/libcrypt implementation

glibc provides many interfaces and there's a steady process to deprecate some of these built-in implementations to allow other providers on the system to better fulfil their purpose.

Gentoo has already done this before with:


 * SunRPC to libtirpc
 * NIS to libnsl

This time, we're working on replacing glibc's libcrypt with. This effort is being tracked in.

Preliminaries
Don't skip these!

1. Please ensure you're using FEATURES="preserve-libs" (default) for now !

2. Fully upgrade your system ( or similar). This is critical to mitigate possible Portage issues.

3. Depclean.

/etc/portage changes
This is now obsolete as the changes have now been made in tree.

Upgrade system
Perform a full world upgrade again. If all is going well, you should see a lot of rebuilds caused by.

Nudge the virtual
In some cases, confusing conflicts have appeared.

If this happens, it's recommended to nudge the virtual first:

Then complete a full world upgrade.

static-libs conflicts
Even with the nudge, you may still get some conflicts. It's possible they're to do with USE=static-libs.

Make sure that static-libs consistently enabled on both  and   if a package e.g.   or   requires it:

Then try the nudge again, then a full world upgrade.

With explicit reverse dependencies
Where the above  and   did not help rebuilding all reverse dependencies of, handing that list to portage explicitly has been proven to work in some cases. All it takes is either  (of ) or   (of ) to gather the list and glueing things together in shell:

For the variant using :

For the variant using :

What this does is collect reverse dependencies, take the first word of each line, prepend "=" to each line, and forward the resulting lines to.

This works because we're forcing Portage to consider rebuilding both libxcrypt and any packages which must be rebuilt together with it simultaneously.

Circular dependencies
A Portage (arguably PMS) bug (and its many duplicates) mean that the   eclass pulls in the latest version of Python even if it is not listed in PYTHON_TARGETS.

This can manifest as:

In this case, please try.

Blockers
On one occasion, a nonsensical blocker occurred (on a more outdated system):

Do NOT attempt to unmerge glibc.

In this case,  was sufficient to install the new glibc[-crypt] and allow a subsequent world upgrade to be cleanly calculated (even if it looks scary):

Expected problems

 * Largely should be smooth when building applications
 * Fedora switched in 2018 and have hit few issues, upstreaming patches where they did (rarely) hit something
 * Missing dependencies on (or missing subslot operator :=)
 * Note that while it's possible (not verified) we could avoid some rebuilds, this is both not guaranteed and doing the work now allows us to migrate to -compat on libxcrypt in future with a revbumped virtual (not yet possible due to so many pre-built binaries requiring compat).

Developer information
gyakovlev has implemented a QA check to ease finding missing dependencies.


 * If your package links against, you need to explicitly depend on   in DEPEND and RDEPEND.


 * Please do revision bump (straight-to-stable) your package (recommended: ) when adding a either the dependency or a subslot operator for it. Revbump all versions in tree to avoid the need for stabilisation later and to apply the change consistently.


 * Note that false positives can occur with as-needed, as ever. Please see Project:Quality_Assurance/As-needed and.


 * If your package doesn't link against  but uses it otherwise (e.g. runtime dlopen), please ensure you RDEPEND on   (no := required for rebuilds).


 * If your package doesn't use, no action is required.

TODO

 * 1) Get sufficient testing on tinderboxes (ago, toralf, ...)
 * 2) * sam is going to switch to libxcrypt for arch testing too
 * 3) Ensure we're happy with the virtuals
 * 4) Discuss plan for migration (draft news item, ...)
 * 5) Achieve full set of keywords
 * 6) Finalise keywording in  (as of writing, only ~m68k remains)
 * 7) Stabilise a version of libxcrypt on all architectures where we have stable glibc, ongoing in

Migration plan

 * 1) Revbump  with IUSE="crypt" (not +crypt)
 * 2) Revbump sys-libs/libxcrypt with IUSE="+system"?
 * 3) Unmask the virtual
 * 4) Migrate masks to musl + uclibc-ng profiles? (... and include a force on the m68k prices until they keyword it?)

Future work
We can look into buildling libxcrypt with -compat in the distant future (and even then, not guaranteed), but this is not doable for now given the large number of binaries which expect glibc's libcrypt.

We can consider making another version of the virtual which is indefinitely masked for this. Please note that it's not possible to migrate back to glibc's libcrypt if you disable the compatibility interface in libxcrypt.

= See also =


 * Fedora's notes
 * A set of notes/instructions by sam on migrating systems manually