Declarative diversions



Introduction


A diversion is when it is possible to have dpkg not overwrite a file when it reinstalls the package it belongs to, and to have it put the file from the package somewhere else instead.

Declarative diversions involves a new control file with a declarative syntax which dpkg will parse and process directly as part of the package unpack and removal phases, eliminating the problems resulting from non-atomic handling of diversions.


Topics


There are a number of topics involved in implementing this kind of project


Details - Control File Syntax


It will conform to RFC2822 style with the following format:

'Divert-To' will be optional and if it is ommitted then files being diverted will have their filename changed to 'file.distrib'

The above style has it's advantages, one of the main ones being that there is no need to escape whitespace within filenames. It also allows for more commands to be added at a later date.


Details - Control File Handling


Within control.tar.gz the file should be named 'diversions' This file is then copied to /var/lib/info/$package.diversions We need to store the control file for the currently-installed package so that we can detect declarative diversions that have been removed from the control file between versions (On-disk version and the to-be-unpacked version).

If there is no previous version of a control file then all current diversions within the package are left in place and any new ones declared within the control file are added. If there is a previous version of the control file then the diversions listed within the file are compared with the diversions currently in place. If a diversion exists that is no longer listed in the control file then it is removed. If there is a diversion listed in the control file that doesn't currently exist then it is added.


Details - Handling Diversions to non-existant directories


Diverting files to directories that don't exist can cause a number of problems. If the package does not 'own' the directory it may be left orphaned on removal of the package The package is responsible for ensuring the availability of the target directory in the unpack phase.

If a declarative diversion attempts to divert a file to a folder that neither exists already on the filesystem at unpack time, nor is shipped within the package, dpkg will return an error at unpack time.


Details - Ordering Requirements


Unpacking a new package that adds a diversion


Unpacking a new package that removes a diversion


Removing a package which had a diversion


Details - Error handling


Errors in diversions will have to handled with a great deal of care due to the fact that if they are not the package could be broken. This means that a great deal of checks must be done to ensure that all the files can be diverted properly before any actual diverting takes place. If they can't the package installation/update must be stopped and rolled back to avoid the package being installed incorrectly or broken.


Details - 'dpkg-divert'


When we impliment the new diversion method we should keep the current dpkg-divert. This allows maintainers to catch up with the new method without breaking their packages. It also allows maintainers to perform some operations that aren't support by the new method. All current functionality of dpkg-divert will be left intact for use by sysadmins and for maintainers to catch up with the new system. The two systems will work together without directly conflicting with each other.


Example Usage #1


The file to be diverted is '/usr/share/foo'

It needs to be moved to '/usr/share/bar'

The syntax of the control file would be:


#Start File
Divert-From: /usr/share/foo
Divert-To: /usr/share/bar
#End File



Example Usage #2


In this example the maintainer doesn't want to move the file to any specific folder

The syntax of the control file would be:


#Start File
Divert-From: /usr/share/foo
#End File


This would divert the file to '/usr/share/foo.distrib'


Footnotes


RFC2822 Guide:

First Email Thread on Declarative Diversions (First Message in Thread):

Email thread on first design draft (First message in Thread):

Declarative Diversions Wiki:

My Blog for this Project: