Differences between revisions 17 and 18
Revision 17 as of 2019-02-11 09:02:30
Size: 7840
Comment: Add section: A Note on Package Transitions in The Backports Suite
Revision 18 as of 2019-09-07 17:56:59
Size: 7756
Editor: nodiscc
Comment: add CategoryPackaging
Deletions are marked like this. Additions are marked like this.
Line 90: Line 90:
## If this page belongs to an existing Category, add it below.
## CategorySomething | CategoryAnother

CategoryPackaging

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:


CategoryPackaging