[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

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:

> 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.

> ------------------------+-----------------------+---------------------
> 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.

> ------------------------+-----------------------+---------------------
> 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.

> ------------------------+-----------------------+---------------------
> 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.

> 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.


Reply to: