Re: Proposal: drop libcrypt-dev dependency from libc6-dev
Hello fellow developers,
On Thu, Apr 10, 2025 at 07:37:32AM +0200, Helmut Grohne wrote:
> how about libc6-dev stops depending on libcrypt-dev?
with minor disagreement in details, I have received much positive
feedback and therefore moved forward.
> So far so good. That's 1 + 95 + 11 + 1 = 108 source packages from the
> perl ecosystem in need of changes. What about others?
All of the perl ones have been filed and gregor already fixed (thanks!)
a significant fraction including all 11 perl-xs-dev <!nocheck> ones. I
guess that on third of these is fixed in git or unstable.
> 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.
Bugs with patches are filed for these.
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=helmutg@debian.org&tag=libcrypt-pkgconf
Notably, libuser is missing as I did a QA upload instead.
> 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.
...
> 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:
I have not yet filed bugs for packages lacking "Build-Depends:
libcrypt-dev". That's a next step. I consider the perl-xs-dev
dependencies and the runtime dependencies more important as both of them
also affect other use cases (such as cross building).
> I'd appreciate explicit replies from:
Thanks for the quick feedback!
Regarding the timing of the glibc upload, I also am in favor of not
upgrading lots of these bugs to rc severity. Given the usertags, we may
monitor how the situation evolves in forky. I suggest once the remaining
unfixed bug count (across all categories) is 30 or less, we may proceed
and upgrade the remaining ones to rc.
Helmut
Reply to: