help-libidn
[Top][All Lists]
Advanced

[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,
наб

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]