deb 'streams', 'capabilities', relocation
Hi,
[NB: Not a developer, not a deb file format expert]
There was recently some speak about upgrading dpkg and/or the .deb file
format. I've given some thought to this the other night (and over a few
months) because of a persistent problem with multi-system
installations. I used to administer a network of Sparcs each mounting a
common /usr/local hierarchy (/usr/local/32 and /64 on the server, for
Ultra and non-Ultra archs); full NIS, etc. This may be less of an issue
today (disk space was a serious factor, nevermind administrative
overhead) but recent discussions about documentation translations show
that the concept can still be applied.
The .deb file format consists of two 'streams' (to my knowledge): the
'data' stream and the 'control' stream. Maybe the term 'stream' here
could be replaced with 'capability', but the concept is the same.
The control stream provides installation and removal scripts, as before.
The data stream provides the binary, datafiles, etc.
Now, there is a lot of stuff going into 'data' that not everybody wants
or even needs. A major complaint is l10n data - I know I don't need 99%
of the translations provided by many i18n-ized packages.
In light of this, would it seem unreasonable to create a 'l10n' stream
in the .deb file, providing the various translations to different
languages? I would like to hear some input from the debian-jp people,
but I imagine it would work something like the following:
The .deb format contains a new header, "Capabilities:" which will
specify "l10n" as a capability. If this does not exist, assume an
American/English installation. If it does, consult the file
/etc/debian/capabilities/l10n for rules concerning how to deal with
package installation. For instance, this file could look like:
/etc/debian/capabilities/l10n:
[Languages]
Require: British/English; American/English
Require: French
Install: Japanese
[Default]
Reject
This would indicate that either British English or American English must
be present, with a preference of British English, that French must be
present, and to install Japanese if present. If the package capability
'l10n' is not present, do not install it at all, and do not list it or
consider it available in dselect, or apt-find.
The file hierarchy /etc/debian I chose for clarity; for LSB style
purposes, /etc/sys/pkg/capabilities/l10n may be a better name. But
whatever.
Creating the 'l10n' stream would definately make building packages more
cumbersome, unless the software always uses gettext, in which case
certain assumptions can be made. This does not seem unreasonable until
a better i18n tool comes along, and then it can just be another option
to buildpackage (if that is indeed to more popular package making tool).
Another capability that I would like to see is "Relocatable". This
option would allow you to move a package from the default location, say
/usr/bin, to a shared structure, like /export/linux/i386/bin.
The method I have in mind for making this possible would not require the
assistance of a package building tool. Quite simply, when doing a
'configure', make the target directory something like
'--prefix=/DEBIAN_RELOCATABLE_PACKAGE_FORMAT_DEFAULT_TARGET_INSTALL_DIRECTORY=/usr/bin//'.
Then add the 'Relocatable' capability to the package. When dpkg sees
this capability, it will parse all executables for the above string,
which starts with a '/' and ends with a '//', and contains '='. The
path after the '=' and before the '//' will be used as the default if no
relocation is needed, else this entire string will be replaced with the
specified target location (up to a limit of ~67 characters, or dpkg can
be smarter and include the default path in the max length calculation).
This scheme should work for all executables compiled against libc or
c++, where strings are terminated with a 0x00. Something like libada
may have problems. Shell scripts (files starting with shebang '#!')
will have to be treated differently. Since we can't just srop in a
0x00, we have to do one of two things:
Put "^M#" where the 0x00 would be written for C. The maximum string
length would have to be shortened by one, and this assumes that '#' is a
comment. Or
Put "^M" and delete up to the next ^M character. This would modify the
overall length of the file, which is something that I personally don't
care for, but is not wrong. Ideally, anything scripted would use
relative paths, but that's ideally...
Something that may be off issue even for binary files is trailing
characters. For instance, if we are parsing for relocatability and find
`` "/DRPFDTID=/foo//"(0x00) '', we can't just put 0x00 on the '='
character, as the last " is probably significant. As such, the pattern
is really: [/DRPFDTID=][/default/path]//[trailer]0x00, and the section
[trailer] will need to be copied as well. Again, we'd have to assume
that all strings are 0 terminated, or ^M terminated for scripts. But
for the application of these string (paths to filenames) it should be a
safe assumption, and if not, easy enough to fix upstream.
Here is how I would structure the configuration file:
/etc/debian/capabilities/relocatable:
[Default]
ask # install, fail
/usr/bin: /usr/export/linux/i386/bin
/usr/share: /usr/export/share
/usr/lib: /usr/export/linux/i386/lib
[...]
[amanda]
/usr/bin: /usr/export/linux/i386/bin
/etc: # do not relocate
[...]
[foo]
[...]
The idea here is that for each package that is relocatable, it will have
an entry here. For packages being installed that don't have an entry,
use those set in the default, based on the setting of the first line.
Install will simply install the package unattended. If there is no line
for a relocate line (eg, the package wants to install to /foo by
default, by [Default] doesn't specify a relocation for /foo), install
will fail. If the first line is 'ask', then each relocation will be
confirmed during installation. 'fail' will not install any relocatable
packages if they are not already installed. This is mostly useful if an
existing package becomes relocatable.
Of course, the 'control' scripts will have to also be parsed for this
string.
Further, I was thinking that maybe there could be an 'extradata' stream,
but that seems unjustified now. I was thinking things like
gimp-data-extras could go in here, or additional documentation that
comes with the package. I think my thinking was to cut down on the
number of packages, since many people seem to complain about package
bloat, but I don't think I could justify downloading a 15MB package to
get the 6MB of stuff I want to install (if I don't install the extradata
stuff). Documentation adds another layer of i10n problems anyway.
The other thing I would like to see is a way to make update-rc.d changes
persist across package upgrades, and I'd still like to see all "if [ -f"
tests for executables change to "if [ -x" tests. I don't buy the
argument that it should fail if the file exists but is not executable
because if it ever *should* fail, or it should fail in case of error,
then why check for error at all?
thoughts?
Christopher
Reply to: