PackageDependencyFieldBreaks

Differences between revisions 1 and 3 (spanning 2 versions)
Revision 1 as of 2006-06-14 10:13:47
Size: 2887
Editor: chiark
Comment: own page
Revision 3 as of 2006-06-21 13:19:28
Size: 4397
Editor: ALagny-109-1-2-202
Comment: paste dpkg.org wiki sourcre
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:

Implement the already-specified Breaks package dependency field in dpkg and higher layers.
Line 5: Line 7:
Implement the already-specified Breaks package dependency field in dpkg and higher layers. See https://launchpad.net/distros/ubuntu/+spec/replacement-package-auto-installation.

Formerly half of PackageDependencyFixes which has been split into this spec and ReplacementPackageAutoInstallation.
Line 28: Line 32:
http://www.dpkg.org/Breaks (currently down unfortunately)
Line 30: Line 33:
and copy of dpkg wiki below.
Line 54: Line 58:
= From dpkg.org wiki =
= Breaks =

== Status ==

 * Created: [[Date(2005-07-17T11:45:27Z)]] by ScottJamesRemnant
 * Status: DevelopmentProposal

== Details ==

The basic idea is that, roughly, Breaks is to Conflicts as Depends is to Pre-Depends. Conflicts requires that the conflicted-against package isn't even unpacked when the conflictor is unpacked, while Breaks allows the two packages to coexist on the system but (with {{{--auto-deconfigure}}}) deconfigures one of them. Breaks would be appropriate in cases where

{{{
Conflicts: foo (<< some-version)
}}}

is currently used to indicate that {{{foo}}} needs to be upgraded to {{{some-version}}} or newer in order to work with the conflictor.

This is much more important when using the traditional dselect methods than when using apt, which goes to a lot of extra effort to do upgrades in an order that requires only one run. Even so, the use of Conflicts everywhere makes the system as a whole quite brittle, and has made upgrade ordering painful for a long time now (Ian told me that dselect methods originally weren't supposed to have to do any ordering at all apart from a simple Pre-Depends check); it's an obvious missing feature in our dependency system. It's probably not top of our list of things to do, but we should certainly not forget it.

Summary and Status

Implement the already-specified Breaks package dependency field in dpkg and higher layers.

See https://launchpad.net/distros/ubuntu/+spec/package-dependency-field-breaks

See https://launchpad.net/distros/ubuntu/+spec/replacement-package-auto-installation.

Formerly half of PackageDependencyFixes which has been split into this spec and ReplacementPackageAutoInstallation.

Rationale

It is very likely that many problems with installation are traceable to the ubiquitous use of Conflicts where Breaks would be better - eg, deinstallations of ubuntu-desktop - but most of these consequences probably go unreported. Even with the new distro upgrader life will be easier without these. Furthermore, use of Breaks instead would mean less deinstallation and reinstallation of packages and so might reduce or eliminate the impact of other bugs.

Breaks will replace almost every use of Conflicts << without Replaces <<. This will reduce the amount of churn needed during upgrades, as packages will no longer need to be removed. Installation ordering will be less criticial. This will make upgrades less fragile. In particular, it should eliminate most semi-accidental removals implied by the dependency system, and switching routine use to the less-dangerous Breaks will reduce the total amount of damage done by incorrect dependencies. It may also speed up upgrades.

Use cases

Breezy i386 contains 909 instances of Conflicts << in main; 1921 overall. There is scope for considerable improvement here - Breaks would get rid of nearly all of these.

Scope

dpkg and apt and other programs which read/write status files need to be taught about Breaks so as not to mind it.

dpkg needs to be taught how to apply Breaks (usually, deconfigure packages if necessary).

apt does not need to consider Breaks although it might be useful to try to minimise the aforementioned deconfiguration.

Design

Breaks: http://lists.debian.org/debian-devel/1997/10/msg00643.html and copy of dpkg wiki below.

Implementation

  1. dpkg proper will have to be taught about Breaks; this involves new code in many of the dependency-handling situations.
  2. other code in dpkg will need updating a bit too (eg, dpkg-source et al)
  3. apt should ideally be taught about Breaks; this involves new code in its dependency handling too
  4. Various other packages will need minor edits.
  5. If we switch to smartpm we should educate that too, at least as far as we educate apt.

Compatibility and upgrade process

TBD

Q and A

Q. Is it really better to allow programs to break than to force stuff to be removed ?

A. The programs will be deconfigured (which is the proper way to avoid bad consequences from them not being properly installed). It is actually wrong to remove them because we don't want them to be removed; really we just want them upgraded (in most of these cases).

Outstanding issues

BoF agenda and discussion

From dpkg.org wiki

Breaks

Status

Details

The basic idea is that, roughly, Breaks is to Conflicts as Depends is to Pre-Depends. Conflicts requires that the conflicted-against package isn't even unpacked when the conflictor is unpacked, while Breaks allows the two packages to coexist on the system but (with --auto-deconfigure) deconfigures one of them. Breaks would be appropriate in cases where

Conflicts: foo (<< some-version)

is currently used to indicate that foo needs to be upgraded to some-version or newer in order to work with the conflictor.

This is much more important when using the traditional dselect methods than when using apt, which goes to a lot of extra effort to do upgrades in an order that requires only one run. Even so, the use of Conflicts everywhere makes the system as a whole quite brittle, and has made upgrade ordering painful for a long time now (Ian told me that dselect methods originally weren't supposed to have to do any ordering at all apart from a simple Pre-Depends check); it's an obvious missing feature in our dependency system. It's probably not top of our list of things to do, but we should certainly not forget it.


CategorySpec

PackageDependencyFieldBreaks (last edited 2008-08-06 16:20:56 by localhost)