Bug#810164: perl-modules-5.22: Unversioned Breaks against perl-modules should be a Conflict

Adam Conrad adconrad at debian.org
Fri Jan 8 21:07:10 UTC 2016


On Fri, Jan 08, 2016 at 12:22:50PM +0200, Niko Tyni wrote:
> On Wed, Jan 06, 2016 at 11:06:35PM -0700, Adam Conrad wrote:
> 
> > 1) The "hint" for complete replacement of A with B for high level
> >    dpkg frontends is an unversioned Conflicts/Replaces pair.
> > 2) Virtual packages are defined as a Provides, or Provides/Conflicts
> >    if they shouldn't be installed together, or Provides/Conflicts
> >    and Replaces if they have file overlaps.
> 
> is very helpful.
> 
> The general impression I have is that as Conflicts imposes much
> stronger constraints on upgrade ordering, it should be used sparingly.
> To that end, I'm wondering if we should have perl-modules-5.22
>  Breaks: perl-modules (<< 5.22.0~)
>  Provides: perl-modules
> but leave the Replaces out, effectively dropping the (currently broken)
> "hint" for complete replacement and letting the dpkg frontends to figure
> that out themselves. Do you have an opinion about that?

The only hint that frontends are guaranteed to understand for swapping
packages is Conflicts/Replaces, apt itself will suggest removal of
packages to try to reach your upgrade goal, but more cautious frontends
like unattended-upgrades or update-manager will only allow removals in
that one specific case, to avoid unintentional removals.

> I see you've filed this at severity:important. While I'm not disputing
> that, is there some specific trouble this is causing?

I filed it as important because it stalls upgrades with the above-
mentioned "cautious" frontends and forces user intervention with apt
or dselect/aptitude to get the desired result.

Given the above, I think the only reasonable solution right now is to
move your Breaks to a Conflicts.

As a side note, you may also want to make your Provides versioned, as
having it unversioned has suddenly swapped meaning for dependencies
such as:

 Depends: perl-modules (>= 5.10) | libcgi-pm-perl (>= 3.35)

An unversioned Provides is evaluated as version 0:0.0, which means an
upgrade that's removing perl-modules will pull in libcgi-pm-perl, even
though that shouldn't be necessary.  A versioned Provides would fix
that.

... Adam




More information about the Perl-maintainers mailing list