Packaging system improvements
The new interface in deity is now seeming to need many new packaging
features. Since really new features haven't been added to the
packaging system in a fairly long time, and the number of packages is
now getting very large, I am going to suggest several possible
improvements to the system here. I think we should discuss them, and
start implementing them soon for Debian 2.0.
Therefore, I have drawn up a document which lists the current
feature-requests and other requirements for the packaging system. It
would probably also be a good idea to create a new mailing list to
discuss packaging system development on (debian-dpkg?).
Here is the list of current issues. I will add to it any that other
1. We need to add a "Keywords: ..." line to the control file for each
package. However, the success of this depends more on the keywords
individual maintainers put in their packages keyword lists than the
presence of special features for it.
2. We need a way of including and excluding specific directories from
the install of a package, or moving them. This will be dealt with
by deity, but the main "dpkg" program should also be capable of
3. (All related to source packaging)
3a. We need to standardize on a location where Debianized sources
installed on a system should be put, and the format of this tree.
3b. We need a method to automatically retrieve and install source
packages as we can currently do for binary packages with
3c. We need to be able to use pristine upstream sources, to allow
paranoid users to check the upstream validity (with PGP or
whatever). This also entails the need to use more than one
upstream source file, and source fies with odd extract locations.
3d. We need to be able to distribute cleanly Debian
source-modifications if we can't distribute upstream sources.
3e. We need a method of building packages as a non-root user.
3f. We need "Source-Depends". This in turn dictates that we need a
3g. (Not required yet) It may be useful to have a system for
automatically bootstraping a new archtecture for Debian by
building a cross-compiler, then building the basic system plus
development tools with the cross-compiler.
4. We need a generalized library providing functions for accessing the
packaging system. Particularly, this is currently needed by the
"menu" (and possibly also "dwww") package(s).
5. We need to speed up the initial reading of the files when dpkg is
invoked. The reason for this slowness is that in
/var/lib/dpkg/info, there are a great many (580 on my system)
files, and a large amount of these are read upon startup (*.list,
*.conffiles) of dpkg (244 on my system). This can be done using a
libdb database, and stat'ing the /var/lib/dpkg/info files on
6. We need a method of doing configuration as a separate action from
installation. This means that configuration can be done before
installation and after installation fairly easily. The best
solution would ideally use the textdb interface for
this. Configuration should therefore not (a) depend on the package
being unpacked, or (b) require anything to happen on the machine
which is being configured (so that a machine may be configured over
7. Further to <2>, but much harder to implement (possibly), is the
concept of file types. Then, the user can select to include or
exclude a specific file type, e.g. they could exclude the "binary-i386"
type, or even nicer, redirect them, e.g. "/usr/bin[binary-i386] -->
7b. Following on from <7>, this means that dpkg would possibly need to
be changed to handle multiple architectures!
8. Dpkg defaults need changing so that "force-overwrite" is no longer
9. Currently, we have a problem with the architecture field as used by
dpkg. It assumes that the architecture is Linux. This means that
there is a fairly poor portability to other Operating Systems. For
example, "mbr" is a generic i386 package, but most are Linux-specific.
 The textdb is (a) currently in experimental, and (b) does not
provide a shared-library interface. A shared library interface
would be more desirable (as it would be faster).
 Maybe we could even provide an SNMP interface to the textdb to do this!
Here is some more detailed information about the current status of
some of these issues, and how they might be solved.
3a. I propose we use "/usr/src" as the base location, and then divide
the packaged into sections as done with the archive in binaries,
so e.g. the source for CVS would be unpacked into
"/usr/src/devel/cvs-1.9-4". We might also want symbolic links for
binary package names, e.g. "/usr/src/devel/cvs-pcl".
3b. This means we need "Packages.src" and "Packages.src.gz"
files. These should mention the ".dsc" files, which should then be
retrieved to find the specific files needed. Alterntively, why not
just cat all the .dsc files together appropriately.
3e. Already, "debian/rules build" should work as non-root. Since dpkg
does not always preserve file permissions from an unpack (in the
case of files already existing), I suggest that we make it policy
that every package move over to the suidmanager package. This
means that dpkg-source can be modified to build the archive with
everything owned by "root.root", and a substitute "install" script
(along with chown) can be written to append appropriate fragments
to DEBIAN/postinst and DEBIAN/postrm. However, this does not take
into account "perl" programs, etc., or hard links.
6. Bruce has already suggested on debian-admintool one way to do
this. Basically, the idea comes out like this:-
preconfig.sh - run on the machine *BEING configured* before
config.sh - gets configuration, stores in textdb
postconfig.sh - does the configuration.
For deity, I have been developing a system which allows transparent
access to the user interface to ask questions of the user,
etc. This eliminates the possibility of "config.sh" being a shell
script. The language I have been looking into is "S-Lang". However,
this may not be good, as not all developers know this language (it
is fairly C-like, but has the odd strange bit).
9. I suggest we add some new architectures. To allow backward
compatbility, the "standard" names will still mean the Linux
variant. So, e.g. "i386" actually means "i386 Linux". Then, you add
suffixes to the architecture like this:-
i386-generic - For generic programs, like mbr.
i386-nextstep, etc. - Used for other OSs (kernels).
So, I suggest that we aim to evetually change the "i386" part to
"i386-linux" (Debian 2.1), but support compatibility as just "i386".
Tom Lees <email@example.com> <firstname.lastname@example.org> http://www.lpsg.demon.co.uk/
PGP Key: finger email@example.com, http://www.lpsg.demon.co.uk/pgpkey.txt.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .