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=helm...@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
