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.

Contents

  1. Package Transition
  2. A Note on Package Transitions in The Backports Suite
  3. See also

Package Transition

Basic scenarios

Let's assume package version to be

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?

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:

CategoryPackaging