[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

`overriding' dpkg for a particular file



I'm almost finished with the implementation of a feature for dpkg that
will allow the sysadmin or package maintainer to prevent dpkg from
overwriting a particular file.

Instead, whenever dpkg finds a package containing that file it
`redirects' the reference to an alternative name.

Eg, if you were to `override' /usr/sbin/smail and `redirect' it to
/usr/sbin/smail.real then any package containing /usr/sbin/smail would
have the file placed as /usr/sbin/smail.real instead.
The feature will work during package removal, as well.

There's provision for a single package to be named which is allowed to
provide a version of the file which will installed under the original
name.

This feature shouldn't be mixed with the conffiles update mechanism,
as this is unlikely to produce useful results and likely to produce
confusion on the part of the user at the very least and possibly on
the part of dpkg too :-).

No package should contain a file whose name is the `redirected' name
of another file; dpkg will spot this and balk if such a package is
installed when the redirection is in place, or if a redirection is set
up which involves overwriting an existing file (whether managed by
dpkg or not).

Only one redirection for a particular file is allowed, and you can't
redirect A to B and then B to C.

There is one thing I would like some comments on: what names should I
give to the particular aspects of this feature ?

Currently I'm working with:
 `overrides' as the name of the feature;
 `contested file' or `file' as the file copies of which dpkg will
    divert.
 `alternative name' or `divert-to' as the name that dpkg will use
    instead.

This terminology all seems rather clumsy.  Suggestions are invited;
post to debian-devel and I'll pick the ones I like - no democracy here
:-).

This feature is intended to be used sparingly; a system administrator
can use it to keep a locally-installed version of a piece of system
software that has to live in a particular place.

A package should preferably only use it if the package's main function
is to replace the file in question (whether or not the `original' or
`overwritten' or `other-package' version of the file needs to be
available); otherwise a sysadmin might find that the feature wasn't
available to them when they wanted to install their own version of the
file because a package had already done so.

It's possible that I might introduce a facility that would allow
*requests* for redirection of files to be redirected themselves, by
using a special 2nd-level redirection option.

Ian.


Reply to: