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

Re: RFC: Idea for improved diversions and alternatives handling

Goswin von Brederlow wrote:
> working on dpkg reminded me that I wanted to propose a better
> diversion and alternatives handling for debian packages. Currently
> they have to be manually added and removed in the maintainer
> scripts. This method is prone to errors and can easily leave
> diversions or alternatives behind. Instead I suggest creating two new
> control files detailing the diversions and alternatives a package
> should have.

Can symlinks be supported in the declarative control file stanzas?

One problem within Emdebian is replacing coreutils etc. with busybox -
currently we are having to use a rigid replacement where the options
enabled in busybox must be removed from the package set (or added as
Conflicts: in busybox) and then the symlinks for each applet are listed
in the dpkg file list. This requires a particular level of coordination
and makes it harder to customise Emdebian for a different scenario.

If both /bin/foo and /bin/bar are called during the boot/init process,
the issue is allowing for this scenario:

Install package foo, includes symlink /bin/bar -> /bin/foo
Also includes a variety of others (about 30 in total).

At a later date, the installation needs to be customised to allow the
"full" version of /bin/bar from package bar to be installed for extra
functionality. If Replaces: is used, bar cannot be removed because the
box would not be bootable anymore - the previous symlink has gone

How to divert a symlink such that it can be restored later?

Alternatives isn't a good solution because it means reimplementing the
alternatives support code to avoid the use of Perl - and alternatives
(IIRC) does not support symlinks as alternatives.

What I need to avoid is having to make dozens of changes to postinst
scripts to enable diversions in a long list of packages.

Busybox 1.10.3 (not yet in Debian) does support discrete binaries linked
to a shared library version of busybox but the library is bigger than
the current busybox binary and each discrete binary is just over 4Kb so
that is an appreciable increase in total size. (Seeing as this is
busybox, size increases must be avoided.) It would allow the use of
alternatives (subject to replacement non-perl code) but that method also
needs changes in other packages (currently). So that costs an extra 2Mb
or so and involves rewriting the code supporting alternatives - not my
favourite option when the entire OS has to fit into 32Mb (or 64Mb for a
full GUI using glibc).


Neil Williams

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: