[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Bug#1066855: drop libidn11-dev
From: |
наб |
Subject: |
Bug#1066855: drop libidn11-dev |
Date: |
Sat, 26 Oct 2024 20:28:39 +0200 |
User-agent: |
NeoMutt/20231221-2-4202cf-dirty |
Hi!
On Sat, Oct 26, 2024 at 07:35:20PM +0200, Simon Josefsson wrote:
> наб <nabijaczleweli@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