PackageDependencyFixes

Differences between revisions 4 and 5
⇤ ← Revision 4 as of 2006-06-05 04:54:17 →
Size: 3046
Editor: fsproxy1
Comment: Fix bogus Launchpad URL
← Revision 5 as of 2006-06-05 15:31:22 → ⇥
Size: 3557
Editor: chiark
Comment: various edits
Deletions are marked like this. Additions are marked like this.
Line 44: Line 44:
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 will have to be taught about Breaks; this involves new code in its dependency handling too.
4. Various other packages will need minor edits.
Line 46: Line 51:
=== Data preservation and migration === === Compatibility and upgrade process ===
Line 48: Line 53:
Not relevant. == 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).
Line 54: Line 63:
LeonardoSantagada: Maybe you should think about using SmartPM(http://www.smartpm.org/), it will not fix all of the problems but it is easier to replace synaptic than to fix dpkg and apt in my opinion.

Summary

Two fixes to the dependency management system in dpkg, apt and higher layers: Implement Breaks, and implement the correct selection behaviour for Replaces.

Rationale

Correct behaviour in the presence of Replaces will allow us to get rid of all `transitional packages'. These are effort to create and maintain and of course cause confusion and cruft.

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.

Breezy i386 contains around 18-29 transitional packages which could be simply abolished. With proper behaviour on Replaces, transitional packages will no longer be required when package names change.

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.

dselect and apt need to be taught about the full meaning of Replaces.

Design

Breaks: http://www.dpkg.org/Breaks http://lists.debian.org/debian-devel/1997/10/msg00643.html

Replaces: when A is selected by the user for installation, and a newly-available package B appears such that (the new version of) B Replaces (the current version of) A, then B should automatically be marked as selected for installation. This is in addition to the other behaviours of Replaces. See http://lists.debian.org/debian-devel/2005/06/msg02045.html, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=47540. This has been a planned intended behaviour of Replaces for some time, as old versions of the Debian Packaging manual show.

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 will have to be taught about Breaks; this involves new code in its dependency handling too. 4. Various other packages will need minor edits.

Code

Compatibility and upgrade process

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

CategorySpec

PackageDependencyFixes (last edited 2008-08-06 16:32:11 by localhost)