Re: Bug#582423: tech-ctte: reaffirm that violating Debian Policy deserves RC bug
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> Goswin von Brederlow writes ("Re: Bug#582423: tech-ctte: reaffirm that violating Debian Policy deserves RC bug"):
>> Just to make sure that means now the following is to be used, right?
>
> Thanks for the helpful presentation of the questions.
>
> Typically the situation involves an old package and a newer one, and
> the idea is that the old package does not need to have anything put in
> its dependencies (since after all the purpose is to deal with it).
>
> So, with the proviso that "A Flags" and "B Flags" refer in each case
> to the new version of each package:
I was looking at it from the point of A existing in the archive while
you prepare a new version of B. But then I found that for some cases A
is required to already have a flag or needs to be updated as well to do
have it. But yeah, it would be nice if only B need to be uploaded.
>> 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. By updating A to be without the file that at
least gets avoided when you upgrade all packages to the same
release. While not required I think it would be good to recommend
updating A as soon as B has entered the archive or the forseeable
future. If A and B come from the same source anyway the point is mood.
>> ------------------------+-----------------------+---------------------
>> Rename A to B | optional make A | Conflicts: A
>> | dummy/transitional | Replaces: A
>> | Depends: B | Provides: A optional
>
> I think this is right but I'd like Raphael or someone to confirm.
> This contradicts what I wrote in my proposed policy fragment about a
> package not conflicting/replacing/providing a single virtual package.
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:
Package: C
Depends: A
Without either a dummy/transitional package or a provides C becomes
uninstallable.
Note: With a dummy/transitional package the Conflicts/Replaces in B must
be (<<) versioned I believe. Or should that be Breaks/Replaces then?
Note2: So far only dummy/transitional package work on versioned depends.
>> ------------------------+-----------------------+---------------------
>> 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.
>> ------------------------+-----------------------+---------------------
>> Implements virtual pkg | Conflicts: virt | Conflicts: virt
>> | Provides: virt | Provides: virt
>
> Often two implementations of the same virtual package can coexist (eg
> because they use update-alternatives or some similar mechanism) so
> Conflicts is optional.
Right. Forgot about that.
>> PS: If this is all correct maybe this overview could be added to the
>> Debian Developer's Reference 6.7. Common packaging situations.
>
> Yes, that would be useful.
>
> Ian.
MfG
Goswin
Reply to: