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 forever. 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 ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
signature.asc
Description: This is a digitally signed message part