6873
Comment: Add clarification provided by nthykier, wRAR, and bunk on #debian-mentors -- feel free to rewrite/reorg/retitle
|
7840
Add section: A Note on Package Transitions in The Backports Suite
|
Deletions are marked like this. | Additions are marked like this. |
Line 9: | Line 9: |
## If your page gets really long, uncomment this Table of Contents | ## If your page gets really long, uncomment this Table of Contents |
Line 16: | Line 16: |
Let's assume package version to be | Let's assume package version to be |
Line 52: | Line 52: |
== A Note on Package Transitions in The Backports Suite == ??: If has stable A, but does not have B, it seems the backport must include B, because packages NEW to testing will most likely depend on B and not A. Thus, backports of packages NEW to testing may be blocked if stable-backports does not have B. When a package in stable has followed "#5 Rename", and the stable release has both A (dummy transitional) and B (new package name), the A package may be removed from the src:package in testing following #12. Let X be the src:package in testing and Y be the src:package in stable-backports. When Y is updated from X at #12, A must be resurrected in Y. If A in stable has optional Provides, or if A is at #3, then these should be retained in Y, resurrecting them if necessary. ??: It seems like the question of "if B Provides: A has been added to ...should Y merge these new Provides or reject them" might be up to the iscretion of the backporter. |
Translation(s): none
This page summarizes several Debian package transition scenarios which require some coordinated tweaks on debian/control file of newly uploaded packages.
Recent Debian Policy (>> 3.8.0) updates on "Breaks" field is accounted here.
Package Transition
Basic scenarios
Let's assume package version to be
- old package: 1.0
- new package: 2.0
case |
Package (transition) situation |
Flags for new A package |
Flags for new B package |
#1 |
Conflicts: never work together |
Conflicts: B |
Conflicts: A |
#2 |
Resolved conflicts: old A and B conflicted with each other and with new ones; only newer A and B can coexist |
Breaks: B (<<2) |
Breaks: A (<<2) |
#3 |
Virtual package: normal virtual package which avoids Conflicts using update-alternatives(8) etc. |
Provides: virt |
Provides: virt |
#4 |
Exclusive virtual package: exclusive virtual package such as mail-transport-agent |
Provides: virt |
Provides: virt |
Conflicts: virt |
Conflicts: virt |
||
Replaces: virt |
Replaces: virt |
||
#5 |
Rename: only A existed; move everything from A into B; make A a transitional package without real contents. See RenamingPackages for an in-depth explanation. |
Depends: B |
Breaks: A (<<2) |
Replaces: A (<<2) |
|||
optional* -- Provides: A |
|||
#6 |
Merge: A and B existed; merge everything from A into B; make A a transitional package without real contents |
Depends: B (>=2) |
Breaks: A (<<2) |
Replaces: A (<<2) |
|||
optional* -- Provides: A |
|||
#7 |
Split: only A existed; move some files from A to B; new A does not require new B |
|
Breaks: A (<<2) |
Replaces: A (<<2) |
|||
#8 |
Split: only A existed; move some files from A to B; new A always requires new B |
Depends: B |
Breaks: A (<<2) |
Replaces: A (<<2) |
|||
#9 |
Reorg: A and B existed; move some files from A to B; new A does not require new B |
Breaks: B (<<2) |
Breaks: A (<<2) |
Replaces: A (<<2) |
|||
#10 |
Reorg: A and B existed; move some files from A to B; new A always requires new B |
Depends: B (>=2) |
Breaks: A (<<2) |
Replaces: A (<<2) |
|||
#11 ?? |
Merge and remove: A and B existed; merge everything from A into B; A does not exist in new archive; B is the functioning package |
(non-existing) |
Breaks: A (<<2) (for backport ease) |
Replaces: A (<<2) |
|||
optional* -- Provides: A |
|||
#12 ?? |
Remove transitional: A existed as a transitional package without real contents in previous release; A does not exist in new archive; B is the functioning package |
(non-existing) |
optional* -- Provides: A (?? is this enough ??) |
*) Provides are needed only when there are some packages which depend on A.
?? marks needs to be checked. #11 and #12 may be wrong.
A Note on Package Transitions in The Backports Suite
??: If has stable A, but does not have B, it seems the backport must include B, because packages NEW to testing will most likely depend on B and not A. Thus, backports of packages NEW to testing may be blocked if stable-backports does not have B.
When a package in stable has followed "#5 Rename", and the stable release has both A (dummy transitional) and B (new package name), the A package may be removed from the src:package in testing following #12. Let X be the src:package in testing and Y be the src:package in stable-backports. When Y is updated from X at #12, A must be resurrected in Y. If A in stable has optional Provides, or if A is at #3, then these should be retained in Y, resurrecting them if necessary.
??: It seems like the question of "if B Provides: A has been added to ...should Y merge these new Provides or reject them" might be up to the iscretion of the backporter.
Unsolved cases
Can you provide solutions for these cases?
Files recently added, then moved: File path /lorem/ipsum did not exist; then, package B version 3 installs that path. Later, package A installs that path instead, and package B version 6 stops installing it.
Too broad: Breaks: B (<< 6) incorrectly breaks earlier versions of B that would work fine (e.g. with a backport of A).
Too broad: Breaks: B (>= 3), B (<< 6) incorrectly declares breakage of *all* versions of B, because the conditions are applied individually.
Invalid: Breaks: B (>= 3, << 6) would be good, but it is invalid syntax.
Terminology
Replaces is used when a new package replaces/overwrites files, and Provides is package provides functionality. Do not use Replaces to say that a package replaces functionality when it does not replace/overwrite files. During a package rename+split, let A be the old package name, let B contains the bulk of the functionality, and let C be something like a library component or server-back-end for B. New A becomes a dummy transitional package that depends on B, and B depends on C. If only C replaces/overwrites files from old-A, then C receives the the Breaks and Replaces flags, and neither A nor B receives Breaks and Replaces flags; however, if B also replaces/overwrites files from old-A then B must also have Breaks and Replaces flags. --NEEDS EDIT: is it ever appropriate for a transitional dummy package to have Breaks and Replaces? Also, please clarify the timeline for migrations, eg: stable+1 has transitional dummy package, stable+2 has transitional dummy package and B Provides A. Stable+3 has no transitional dummy package. In Stable+4 package B can drop "Provides A"?
See also
This document is based on following references and mailing list messages:
Debian Policy Manual, Chapter 7 - Declaring relationships between packages
- manual page: deb-control(5)
Package renaming, and transitional dependencies (before introduction of Breaks)
http://lists.debian.org/debian-ctte/2010/05/msg00012.html and following messages.
http://lists.debian.org/debian-policy/2010/06/msg00222.html explaining why Breaks is needed for dist-upgrade.
conflicts/replaces/provides vs. breaks/replaces/provides under policy 3.9.1 and following messages.
guessing ... (Replacing as much versioned Conflicts with Breaks)