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

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
people suggest.

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
   handling this.

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
    "Packages.src" file.
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[1]. 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
   the network[2]).

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
   the default.

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.

[1] 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).

[2] 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 <tom@lpsg.demon.co.uk> <tom@debian.org>  http://www.lpsg.demon.co.uk/
PGP Key: finger tom@master.debian.org, http://www.lpsg.demon.co.uk/pgpkey.txt.

TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .

Reply to: