PackageDependencyFieldBreaks

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 needs to be taught how to apply Breaks (usually, deconfigure packages if necessary).

apt does not absolutely need to consider Breaks. It would be good for apt to (a) know that Breaks usually means apt should try to upgrade the Broken package to satisfy the dependency, (b) know enough about Breaks to avoid starting an operation which is guaranteed to leave a package deconfigured due to an unfixable Breaks, and (c) know enough to reconfigure packages after dpkg has deconfigured them because of Breaks.

update-manager needs to be taught to run dpkg --configure --pending or some similar equivalent at the end of an upgrade, to configure any packages left unconfigured by apt/dpkg.

Some peripheral programs which read and write status files may need to be taught about Breaks so as not to mind it. We will discover any such programs by deploying the Breaks field.

Semantic design

See http://lists.debian.org/debian-devel/1997/10/msg00643.html

Implementation and deployment plan

  1. Immediately (as soon as possible) dpkg will be changed in edgy so that it will refuse to install any package whose control file specifies Breaks. (Ideally this same change would also go into Debian sid ASAP.)
  2. Proper implementation of Breaks in dpkg will be developed, tested, and deployed into edgy. (Ideally this would be deployed in sid at the same time too.)
  3. Now an announcement can be made that packages should start using Breaks << instead of Conflicts <<. The announcement should describe when to pick Breaks and when to pick Conflicts and should also come with proposed new text for the policy manual. (If the appropriate planning and deployment for Debian has been done then we can hope that Debian maintainers will start to change their packages and will take our patches.)

  4. update-manager's upgrade script will be changed so that packages are not left unconfigured (this is trivial).
  5. If time permits, the improvements in apt described above will be implemented. (a) (upgrades as a result of Breaks) and (b) (avoiding semi-doomed operations) are probably best done together as they are likely to overlap. (c) (reconfiguring at the end of a run, where possible) is probably a separate task. The actual decision as to which to implement will be taken at the time based on the available time and review of the relevant apt source. (The core problem resolver, which is the main target for (a) and (b), is 1200lines of moderately dense C++, so relatively manageable.)

If we switch to smartpm for edgy, some additional thought may be required to gain the best benefit from Breaks. If smartpm ignores Breaks completely we are in the position of 4 but not 5, above.

Plan 5B

If we complete steps 3 and 4 and Breaks is used widely, but we fail to implement 5, there is a possibility that the widespread use of Breaks and the resulting deconfiguration and perhaps lack of reconfiguration of packages will turn out to be a worse problem than the unwanted removal and thrashing that currently happens.

This is not the expected outcome, but the cultural and human-factors variables are not wholly predictable so we must be prepared for this possibility.

If we find that this is the case, we have the option of the following trivial fix:

Change apt to treat Breaks exactly like Conflicts. This will restore the pre-Breaks state of affairs until apt can be taught properly about Breaks. This is obviously not ideal as it negates the benefits of the new field for edgy but it is important to note that this fallback option exists should we need it.

The same applies for smartpm, if we are using it. We can choose separately for each of apt and smart whether we do 5, 5B or nothing.

Semantics - discursive explanation

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.

Acknowledgements

Thanks to Michael Vogt for helpful criticism and to Scott for the discursive explanation which I've cut-and-pasted above from the dpkg wiki.

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).


CategorySpec

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