[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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.


Reply to: