Hi Here is a small update re dropping libidn11-dev. We are now down to these packages:
jas@coccia:~$ dak rm -Rn -b libidn11-dev ... Checking reverse dependencies... # Broken Build-Depends: courier: libidn11-dev courier-authlib: libidn11-dev eiskaltdcpp: libidn11-dev foxeye: libidn11-dev nextepc: libidn11-dev The libidn bug correctly depends on each RC bugs for those packages: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066855 The only package still in testing is 'foxeye' which is slated for autoremoval on 2025-01-18. My plan is to upload what's in the libidn 'wip' branch once all of the above packages are no longer in testing. Please review: https://salsa.debian.org/debian/libidn/-/compare/master...wip As you can see I'm not adding the 'Provides: libidn11-dev', as I don't think it is actually needed. No packages in testing refer to libidn11-dev. Things in oldstable may refer to libidn11-dev, but those packages will be upgraded to trixie versions that no longer mention libidn11-dev. As far as I can tell, the 'Provides: libidn11-dev' would have been necessary if we wanted to drop libidn11-dev in sid/testing before all the reverse dependencies were fixed, but I don't plan to do that since we are so close to finishing the migration. Packages outside of oldstable that refer to libidn11-dev had the bookworm release to migrate away from the transitional package. Does this make sense? I'm not 100% confident on this, package dependency handling during migrations always seems to confuse me. /Simon наб <nabijaczlew...@nabijaczleweli.xyz> writes: > Hi! > > On Sat, Oct 26, 2024 at 07:35:20PM +0200, Simon Josefsson wrote: >> наб <nabijaczlew...@nabijaczleweli.xyz> writes: >> > udd=> select source from sources where build_depends like '%libidn11-dev%' >> > and release = 'sid' ; >> > source >> > -------------------- >> > biboumi >> > courier >> > courier >> > courier-authlib >> > eiskaltdcpp >> > foxeye >> > hesiod >> > jabber-muc >> > jreen >> > libnet-libidn-perl >> > libpodofo >> > nextepc >> > psi >> > psi-plus >> > (14 rows) >> > >> > So so long as libidn-dev gains Provides: libidn11-dev, this should be good? >> >> Nice list. Hmm, is it really sufficient with a Provides to get apt to >> install libidn-dev, when building those packages? > https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual >> 7.5. Virtual packages - Provides >> As well as the names of actual (“concrete”) packages, the package >> relationship fields Depends, Recommends, Suggests, Enhances, >> Pre-Depends, Breaks, Conflicts, Build-Depends, Build-Depends-Indep, >> Build-Depends-Arch, Build-Conflicts, Build-Conflicts-Indep and >> Build-Conflicts-Arch may mention “virtual packages”. >> >> A virtual package is one which appears in the Provides control field >> of another package. The effect is as if the package(s) which provide >> a particular virtual package name had been listed by name everywhere >> the virtual package name appears. (See also Virtual packages) > reads like "yes" to me. > >> Don't we have to file bugs on all of those packages? > This is also probably desirable to drop the Provides post-trixie. > This would leave us with > bullseye: libidn11-dev > bookworm: libidn-dev (real) + libidn11-dev (transitional) > trixie: libidn-dev (real) Provides: libidn11-dev > forky: libidn-dev > and plenty of time for rdeps to migrate. > > Filing something like "Replace obsolete Build-Depends: libidn11-dev with > libidn-dev" > with Control: block 1066855 by -1 Severity: important > and dropping the Provides and upgrading the bugs to Severity: serious > post-trixie is the smoothest transition I can think of, > and gives the long tail (which, going by tracker.d.o, is almost guaranteed) > sufficient time. > >> jas@coccia:~$ dak rm -Rn -b libidn11-dev >> Checking reverse dependencies... >> # Broken Build-Depends: >> biboumi: libidn11-dev >> courier: libidn11-dev >> courier-authlib: libidn11-dev >> eiskaltdcpp: libidn11-dev >> foxeye: libidn11-dev >> hesiod: libidn11-dev >> jabber-muc: libidn11-dev >> jreen: libidn11-dev >> libnet-libidn-perl: libidn11-dev >> libpodofo: libidn11-dev >> nextepc: libidn11-dev >> psi: libidn11-dev >> psi-plus: libidn11-dev >> >> Dependency problem found. > I wanna say this because libidn-dev 1.42-2 isn't Provides: libidn11-dev > so if you were to remove it rn, the build-deps would be broken > (but idk if dak understands Provides at all). > > Best, > наб >
signature.asc
Description: PGP signature
