Re: Bug#582423: tech-ctte: reaffirm that violating Debian Policy deserves RC bug [and 1 more messages]
> >> Action | A Flags | B Flags
> >> ------------------------+-----------------------+---------------------
> >> Move file from A to B | Depends: B (>=) | Replaces: A (<<)
> >> | or Breaks: B (<<) |
> >> | as needed |
> >
> > Yes, but only in the Yes.
> > new A without the file.
>
> If there is no new A then installing A, installing B, removing B will
> leave A with missing files.
Yes. This is inherent in the way file overwriting works; the only
alternative would be to have the file owned by two packages or to
squirrel extra copies away or something.
> By updating A to be without the file that at least gets
> avoided when you upgrade all packages to the same release.
Oh I see. Yes, this should be a temporary situation and A should
always be updated when you use Replaces without Conflicts. There
should always be a new A without the file, and it should normally
Depend on the new B and/or Break the old one.
> >> ------------------------+-----------------------+---------------------
> >> Rename A to B | optional make A | Conflicts: A
> >> | dummy/transitional | Replaces: A
> >> | Depends: B | Provides: A optional
...
> Going the way of a dummy/transitional package is probably better than
> the provides way. But I'm not sure there too. But one or the other can
> be needed:
Yes. I think the transitional packages are usually better, but
it seems that Provides is acceptable. My proposed policy wording
needs to be fixed.
> Note: With a dummy/transitional package the Conflicts/Replaces in B must
> be (<<) versioned I believe. Or should that be Breaks/Replaces then?
Yes, it should be versioned Conflicts/Replaces as Jonathan points out.
> >> ------------------------+-----------------------+---------------------
> >> Makes older A not work | Breaks: B (<<) | Breaks: A (<<)
> >> but newer A is ok | if it conflicted |
> >
> > I'm not sure I follow your suggestion for A flags. If what conflicted
> > with what ? I don't think anything should be needed in A.
>
> Package: A
> Versions: 1
> Conflicts: B
>
> Package: B
> Versions: 1
> Conflicts: A
>
> ===>
>
> Package: A
> Versions: 2
> Breaks: B (<< 2)
>
> Package: B
> Versions: 2
> Breaks: A (<< 2)
>
> If the old A conflicts with B then there is no way around updating A
> along with B to make them coinstallable.
How does the Breaks help here ? It doesn't make the Conflict cease to
have effect so yes if you have a system which has one of the old A or
B you cannot install the other, even the new one, until you have first
upgraded the one you have.
Breaks relationships do not have to be symmetric, unlike Conflicts
which are implicitly symmetric even though they are declared by only
one of the packages.
Jonathan Nieder writes ("Re: Bug#582423: tech-ctte: reaffirm that violating Debian Policy deserves RC bug"):
> I suspect Conflicts: A (<< new version), Replaces: A (<< new version)
> is usually more appropriate.
You are right.
Ian.
Reply to: