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