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

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.

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: