On Wed, Jan 06, 2016 at 11:06:35PM -0700, Adam Conrad wrote:
> Package: perl-modules-5.22
> Version: 5.22.1-3
> Severity: important
>
> Currently, perl-modules-5.22 has an unversioned Provides/Breaks/Replaces
> against perl-modules. I assume there are two things you're attempting
> to accomplish with this:
>
> 1) Force a smooth upgrade from perl-modules to perl-modules-5.22.
> 2) Allow for a perl-modules virtual package to exist with future
> versioned perl-modules-X.XX packages.
>
> In both cases, that Breaks should be a Conflicts.
Thanks for your advice!
Yes, 1) is certainly the intention. I think we want to eventually get
rid of 2), but there's 40 or so both build and runtime (unversioned)
dependencies on perl-modules currently in sid, so we're stuck with it
for now, and it's possible we need to carry it on to 5.24 too.
There are no file conflicts between perl-modules-5.22 and the old
perl-modules real package, so the Replaces is indeed meant in the policy
7.6.2. sense ("Replacing whole packages, forcing their removal"), rather
than 7.6.1. ("Overwriting files in other packages").
The interactions of Breaks, Conflicts, and Replaces weren't quite
clear to me, so this:
> 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?
I see you've filed this at severity:important. While I'm not disputing
that, is there some specific trouble this is causing?
> A good rule of thumb is that if you have a versioned Conflicts, you
> probably wanted a Breaks, and if you have an unversioned Breaks, you
> probably wanted a Conflicts.
OK. All this may have implications for the dual life module handling we
have (for instance libtest-simple-perl and libmodule-corelist-perl),
but I'll get to that in a separate bug once I've thought it through.
Thanks again,
--
Niko Tyni nt...@debian.org
