Hello fellow developers, how about libc6-dev stops depending on libcrypt-dev?
I mean for real. We cannot do it right away. The proposal is forky material of course. Also libc6-dev would still "Recommends: libcrypt-dev", but libcrypt-dev would no longer be build-essential. The obvious "why" question needs an answer. libxcrypt and glibc pose a 2-cycle during architecture cross bootstrap and dropping the dependency solves that cycle. It also is not that many packages that actually use libcrypt-dev as we shall see. Let's move into the "how" part. The easy part is preparing a glibc package with the dependency dropped. You may find one at https://people.debian.org/~helmutg/glibc-no-crypt/build/. Santiago Vila kindly performed an archive rebuild using this modified glibc (and with libcrypt-dev removed) and handed me some logs. I sorted those logs and you may now find them at https://people.debian.org/~helmutg/glibc-no-crypt/logs/. Now we need to talk about numbers. It's 803 FTBFS. Of those, 576 issue a dependency on libperl-dev and since perl #includes <crypt.h> somewhere, libperl-dev should be depending on libcrypt-dev. There are also 95 packages that build a perl extension module without depending on perl-xs-dev. Such a practice causes them to FTCBFS, but with libcrypt-dev that FTCBFS is turned into a FTBFS. Beyond that, 11 packages build a perl extension module for testing purposes and therefore need "Build-Depends: perl-xs-dev <!nocheck>". One package actually embeds a perl interpreter without depending on libperl-dev. So far so good. That's 1 + 95 + 11 + 1 = 108 source packages from the perl ecosystem in need of changes. What about others? I classified 110 of the packages as needing a direct libcrypt-dev dependency as they use it in their source directly. And then we have a few packages that indirectly use libcrypt. The following packages ship a pkgconfig file containing -lcrypt and therefore need "Depends: libcrypt-dev". * guile-2.2-dev * guile-3.0-dev * heimdal-multidev * libapr1-dev * libidzebra-2.0-dev * librep-dev * libuser1-dev * ruby3.1-dev * ruby3.3-dev In addition, gauche-dev has gauche-config that also emits -lcrypt. Now matching this up with the build failures yields four that will be fixed be one of these being modified. There is one further category. 6 packages link -lcrypt without using it in any way. I went right ahead and filed patches: https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=helm...@debian.org&tag=libcrypt-unused So that's modifying another 110 + 9 + 1 + 6 = 126 source packages outside the perl ecosystem. You'll find all of the mentioned categories in the published logs as subdirectories. Please bear in mind that among the packages that FTBFS in unstable, a small fraction would additionally FTBFS without libcrypt and I've missed those. Expect a few more. If we assume all of these changes, we've addressed all FTBFS, but we're not done yet. What about packages that check for libcrypt and silently opt out of it when it is unavailable? Typically those packages would emit a runtime dependency on libcrypt1, right? So I also investigated all apt-cache rdepends libcrypt1. That results in 151 source packages. Of those, a large fraction will already be covered by investigating build failures. Additionally, we had to add runtime dependencies to a few packages above. And then there are 11 source packags that already build depend on libcrypt-dev (mostly to support bootstrapping). So if you disregard all of those duplicates, what remains is 28 packages missed in the FTBFS-based analysis: * alpine * asterisk * burp * ccrypt * courier-authlib * cpu * cvm * freewnn * frr * guestfs-tools * ircii * lighttpd * lsh-utils * mariadb * netatalk * pike8.0 * ppp * python-oslo.utils * python3.12 * regina-rexx * rserve * scrollz * steam-installer * tinymux * ukui-control-center * virt-v2v * x11vnc * xemacs21 I also considered running autopkgtests of glibc's reverse dependencies, but that proved to be harder than expected. In the end, we also need to modify glibc to actually demote the dependency. So now we've reached my final number. 108 + 126 + 28 + 1 = 263 source packages need modifications. Some issues may remain here, but at this time I don't expect large numbers anymore. On the perl side, a practical side effect will be fixing couple of cross builds. Question 1: Do you see important aspects missed in this analysis? Question 2: Do you agree that this change is worth the effort? Assuming "no" and "yes" as answers, I'd like to proceed with mass bug filing. I propose severity normal for all bugs. The additional dependencies can be piggy-backed onto uploads aimed for trixie as their risk of causing breakage is really low. For the perl-related changes we might skip filing the bugs and consider mass-committing the changes for a later upload. The glibc change must not be done during the trixie cycle, but can happen early in the forky one. At that point, the remaining bugs would become RC. Question 3: Can I move forward with the MBF? I'd appreciate explicit replies from: * libxcrypt maintainer Marco * glibc maintainers (e.g. Aurelien) * Debian Perl Group (e.g. Gregor) (high number of affected packages) Thanks for considering Helmut
