Bug#578854: Should "Conflicts" be added to the "Replaces" example for package splitting?
On Tue, 15 Jun 2010, Steve Langasek wrote:
> On Tue, Jun 15, 2010 at 06:51:34PM -0700, Russ Allbery wrote:
>
> > > But it's also overly aggressive, since it forces 'a' version 2 to be
> > > unpacked first, *before* unpacking package 'b' - in which case, what do
> > > we need the Replaces: for at all? This is really a workaround for the
> > > fact that Breaks: didn't exist at the time this part of Policy was
> > > written. With Breaks: a (<< 2) and Replaces: a (<< 2), we can force the
> > > upgrade of 'a' in tandem with 'b', but without imposing the unpack
> > > ordering constraints that cause such big problems for dist-upgrades.
>
> > Ah, aha. (This should definitely be explained in Policy, at least in a
> > footnote.)
>
> Yes, I agree.
>
> > So that implies that, for the typical case of moving a file from one
> > package to another, we should use Replaces/Breaks, and reserve Conflicts
> > for actual file conflicts between unrelated packages (such as libkrb5-dev
> > and heimdal-dev). Is that correct?
>
> That's how I understand it, yes.
Having re-read the discussions, I also think that it's the desired
outcome.
We might want to separate two cases however:
1/ splitting a package (i.e. moving files in a new package)
2/ moving files to another pre-existing packages
The first is best served with:
Package: foo
Depends: foo-data
Package: foo-data
Breaks: foo (<< X)
Replaces: foo (<< X)
The latter would also require a Breaks: foo-data (<< X) on foo to forbid
a downgrade of foo-data without downgrading foo. But I have never seen
this used in practice and I don't know whether packages managers cope
well with this (at least they should, Breaks only impose a deconfiguration
before being able to continue).
Cheers,
--
Raphaël Hertzog
Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/
Reply to: