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

DpkgV2 specs

A long time ago word got out that a couple of people were thinking
of rewriting dpkg. We promised to release the design specification
when we felt it had reaced a reasonably stable state to satisfy
all the curiosity and get your input. That time has now arrived!

Attached to this mail is the text-version of the spec. You can also
browse it online at http://www.debian.org/~bcollins/dpkg2/ .

I'ld like to stress a few points first:
* we do NOT intend to force people to switch to dpkgv2 at any moment.
* I'm not doing this as DPL, merely because I think it's a fun project

At this point we're starting to work on a developers guide that will
contain more detailed information about the various parts of dpkgv2
that are useful for people implementing dpkgv2, who want to write
modules for it, or are just interested in how it works.

If you have any comments please don't hestitate to tell us at
dpkg2@lists.wiggy.net . Oh, and we'll read debian-devel as well,
but I don't want to increase the traffic there too much.

Finally, we want a new name for the project. Unfortunately all
our imagination is spent in improving dpkgv2, so suggestions
are welcome..

On behalve of the dpkgv2,

                DPKGv2 Design and Technical Specifications

                     Ben Collins <bcollins@debian.org>

                   Wichert Akkerman <wichert@linux.com>

       $Id: dpkg2-spec.sgml,v 1.26 1999/07/16 16:41:49 wichert Exp $



     This document contains a design specification for DPKGv2. This
     specification is currently in it's earliest form and is by no means
     complete. It is intended as an outline of the DPKGv2 project and gives
     insight to the goals, reasons, and people behind the project, as well
     as some technical details of the software. For more detailed,
     developer oriented documentation, please refer to the _DPKGv2
     Developers Guide_.

Copyright Notice

     Copyright © 1999 Ben Collins

     This manual is free software; you may redistribute it and/or modify it
     under the terms of the GNU General Public License as published by the
     Free Software Foundation; either version 2, or (at your option) any
     later version.



     1.        Note from the Authors

     2.        Design Goals
     2.1.      Modular Structure (Basic Overview)
     2.2.      Coding Practice
     2.3.      A Seperation of Ways (dpkg, dselect and build tools)
     2.4.      Configuration Management
     2.5.      Frontend Interfaces
     2.6.      A Note on Debian Policy

     3.        Implementation
     3.1.      Source Layout
     3.2.      Build Tools
     3.3.      Library and Modules

     4.        Technical
     4.1.      Library Usage (frontend development)
     4.2.      Module Interfaces

     5.        Example frontend (dpkg binary internals)

     A.        Figures
     A.1.      Libraries and Modules


1. Note from the Authors

     Currently the DPKGv2 project is in it's infancy. As such, this spec is
     subject to considerable changes prior to completion of the project. As
     the project nears a stable release, this spec will evolve into a
     complete white paper of the DPKGv2 API.

     What DPKGv2 hopes to accomplish is revolutionize Debian's packaging
     system just as much as the original dpkg. Over time we have come to
     find we need more than what the current dpkg system has or can offer.
     Building on or trying to incorporate these changes into the existing
     source was considered extremely daunting to say the least. While Dpkg
     is a great achievement functionally, it's source code is
     unapproachable by most programmers. With all the features that users
     and developers are asking for in dpkg, it is better that it be handled
     from scratch in order to have certain design goals in mind while
     developing it.

     Since the free software community is at a crossroads at this point,
     this project will also aim to tackle the diverse package formats that
     have been developed over time. This is not to say that there will ever
     be only one format, but there should be a central way to access all
     the formats available as well as allow new ones to be incorporated
     easily, irregardless of the underlying system (or distribution). The
     design scope of this project should instill cohesiveness by utilizing
     common frontends across all formats through this method.

     In the next few chapters you will get a feel for the basic philosophy
     behind the goals and technical workings of this project.

     We look forward to your comments.

     Respectfully, The DPKGv2 Developers


2. Design Goals

     This chapter overviews the general design goals of DPKGv2. Remember
     that specific functionality is not as important here as the underlying
     structure of the API. The design includes the ability to extend the
     capabilities of the library without regard to the frontend programs
     used by the users. It also includes the basic need for functionality
     being seperated into components in order to allow programs not dealing
     directly with package management, to use and interact with specific
     parts of the package system. Abstraction of the core functions will be
     a must.

2.1. Modular Structure (Basic Overview)

     DPKGv2's initial design concentrates on splitting the core functions
     of a package manager into several easily manageable and well defined
     subsystems. All of these subsystems will be accesible via the core
     library. The library obtains it's functionality through modules (see
     Section A.1, `Libraries and Modules').

2.1.1. Core Libraries

     The core library gives the frontend programs access to all of the
     available package management functions, independant of the frontend's
     interface with the user. For example, the library doesn't care if it
     is a gtk, qt, curses, or command line based frontend, the API allows
     the program to make use of what ever UI it decides on. The core
     library is also unaware of specific package formats and other details
     handled by the modules.

     By making the library API independant of the specific package
     implementations, the frontend can be used for any combination of
     module setup. This simplifies frontend development and leaves the
     majority of the work up to the library and modules.

2.1.2. Core Modules

     The modules work behind the scenes, giving the library it's intended
     functionality. This allows for the addition of features post-install,
     and by third-party developers, thus adding capabilities without
     requiring a recompile of the core library or frontend programs. Each
     module type will have a well defined API to ensure that frontend
     programs need no knowledge of the capabilties supplied by them. This
     will also allow for all frontend programs to benefit from module
     additions and centralize the structure of package management, giving
     way to locally customized systems, alternative archive formats, and
     endless expansion, now and in the future.

2.2. Coding Practice

     The success or failure of a project such as this, depends heavily on
     the approachability of the source to developers outside of the core
     group. Making it easy for others to debug, test and develop for the
     project is the only way to be successful in this area. For this
     reason, practical coding will be adhered to.

2.2.1. Code Management

     Basic code management will be instilled from the project inception.
     Source code will be kept in a CVS repository (anonymous access will be
     available once there is a sizeable code base). All core developers
     will have read/write access to the repository and patches from outside
     the core group will be accepted as long as they meet the requirements
     of coding style and stability. Generally speaking, third-party modules
     will not be accepted into the main source tree. An alternative source
     tree for third party modules may be maintained later in the project's

2.2.2. Cross Platform Compatibility

     When at all possible, the library and core modules will support as
     many of the standard platforms (yes, this even means proprietary
     platforms). Also, coding practices will be aimed at using standard
     (POSIX and ANSI compliant) functions from the C library. The more
     places this can run, the better chance of it being used and accepted
     outside of the Debian project. The core library will also not depend
     on anything other than the standard C library and will _not_ use
     external programs to perform functions. This reduces the overhead of
     external dependencies which could break the library inadvertently and
     reduces the effort in porting to new platforms.

2.2.3. DPKGv1 Compability

     DPKGv2's initial goal is to supply DPKGv1 compatibility through a base
     set of modules. It is this basic functionality that will be present in
     the main source tree. Once this is achieved, it is expected that a new
     package format will be derived and allow for simultaneous use of both
     formats. It is also expected that new features will be easily added to
     the current format during the developement phase and transistion to a
     new format.

     The old package format will be developed in the mod_deb2 module. A
     mod_deb3 module has been set aside for development of the new package

2.2.4. Multilingual Support

     DPKGv2 will utilize gettext for supporting locales other than the
     default of english.

2.3. A Seperation of Ways (dpkg, dselect and build tools)

     Currently DPKGv1 focuses on the dpkg binary. Although there is a
     libdpkg, most programs exec dpkg since the API for libdpkg is not well
     defined nor documented. For a package manager to be truely open and
     extendable, a central library must be available for programs to use.
     This prevents duplication of code and incompatibilties between
     different implementations. In DPKGv2, the dpkg binary is not the
     central focus of the development. The dpkg program developed with the
     DPKGv2 project is mainly for transition and to serve as an example for
     frontend development with the library. It is expected that better
     frontends will be developed seperately from this project using the
     DPKGv2 library (curses, GTK, KDE, etc.).

     For this same reason, the dselect program will not be included with
     the core source, since it should be replaced by a better interface.
     This will help concentrate the projects efforts onto the real code
     that handles package and frontend interaction.

     Also, since this project is all about package management for systems,
     it is not within it's design scope to develop tools for building
     packages. It is the opinion of the DPKGv2 developers that package
     building should remain in it's own seperate group of programs so that
     local practices and distribution specific policies can be kept
     seperate from general installation and management.

2.4. Configuration Management

     Yes, DPKGv2 hopes to incorporate internal configuration functions.
     This coincides with the debian-admintool effort. Since packages and
     configuration are so closely tied together, the merger will benefit
     both sides. Configuration management will be developed in the core
     library to be used in conjunction with the other functionality and
     should prove an integral part of future advances in packaging by
     allowing for non-interactive installs, centralized repositories for
     data, network administration and more.

     Several key things will be involved in the config functions. First, it
     will handle all of the persistent data storage for the package system
     (db modules). Data storage will be configurable with modules (ie, db2,
     plain, LDAP...). It will also evolve into a network management
     interface, which could allow for remote frontend interfaces.

     Some key features include the ability to defer obtaining configuration
     information for packages (package format will need to enable this) as
     well as post-installation configuration. Data stored in the system
     will be accessible between packages and programs. The library will
     also enable the development of programs that solely handle system
     configuration. The rest of the package system (including modules) will
     be able to store internal configuration data via this functionality as

2.5. Frontend Interfaces

     DPKGv2's source tree will only come with a `dpkg' compatible binary
     (command line) program. All other frontends will need to be developed
     seperately, but should not be affected by changes in the libraries
     (once the API stabalizes), nor additions/changes in the modules. Once
     the frontends complete the skeletal framework for utilizing the API,
     the rest is left up to the libraries.

2.6. A Note on Debian Policy

     Since DPKGv2's design is not geared toward a package format, it is not
     expected to affect or be affected by policy. The only policy changes
     forseen would be an official implementation of DPKGv2 as the standard
     package manager for Debian, which is not going to be in the near
     future. Extensive testing as an alternative package manager will be
     needed to ensure the stability that is required to support the


3. Implementation

3.1. Source Layout

     The base of the source tree has 5 major branches with several
     subdirectories. The main branches are for the dpkg binary (dpkg/),
     build includes, the libdpkg2 library, the modules (which contains a
     subdir for each core module) and the documentation directory. Other
     subdirectories for utility sources and NLS support are present.

3.2. Build Tools

     DPKGv2's sources use the GNU autoconf and autoheader tools for
     maintaining the configure and Makefile's. This adds immediate ability
     for cross-platform development. In conjunction with this, the libtool
     suite has been implemented for building object files and linking the
     library and binaries.

     Since the entire source will be written C, we will be using GNU gcc
     for most of the development, but any C compiler should work for this
     purpose. The core library also makes use of the libltdl library
     provided with libtool as a dlopen wrapper and is included with the
     main source and statically linked with the core library. This provides
     a simple way of supporting many platforms with modules while keeping
     the source fairly clean and readable.

     GNU's gettext library is included in the source for systems that don't
     have it directly installed on the system.

3.3. Library and Modules

     The core library will be virtually self-standing except for being
     linked with the C library (this includes libdl for the dlopen
     functions where applicable). The versioning scheme for the library
     will follow libtool's suggested syntax of current.revision.age. Here
     is an excerpt from the libtool documentation explaining this

          The most recent interface number that this library implements.
          The implementation number of the current interface.
          The difference between the newest and oldest interfaces that
          this library implements. In other words, the library implements
          all the interface numbers in the range from number current -
          age to current.


4. Technical

     (this is where we get to the nitty gritty...somewhat, save details for
     dev guide)

4.1. Library Usage (frontend development)

     The core library is linked to the frontends and provides total control
     of the package system. (need details on the API)

4.2. Module Interfaces

     There are currently 5 planned module interfaces which give the
     libraries their functionality. (still need to add details to each one)

4.2.1. Package Formats

     dpkg_pkg_*.so -> Used to handle a single package format. These are
     functions for packing, unpacking and configuring packages.

4.2.2. Hooks

     dpkg_hook_*.so -> This class of modules is used in seperates stages in
     the installation and removing of a package. To be exact: before and
     after installation and removal of a package, and just before
     installing or removing a single file/directory from a package. The
     module can decide if we should a) proceed normally, b) skip this file,
     c) use a different filename, or d) abort with an error.

4.2.3. Logging

     dpkg_log_*.so -> Used to supply logging facilities.

4.2.4. Data Storage

     dpkg_db_*.so -> Used to store configuration info as well as persistent
     package status used by the archive modules.


5. Example frontend (dpkg binary internals)

     (here's where we break down the dpkg program provided by DPKGv2 and
     how it uses the libraries in a somewhat non-technical way)


A. Figures

A.1. Libraries and Modules

              +-----------------------+   )
              |    User Interface     |   |
              +---------------------x-+   |
              |                     | |   |- DPKGv2 or 3rd-party Frontend
              |      Application    | |   |
              |                     | |   |
              +-x---x---x---x---x---|-+   )
                |   |   |   |   |   |--------) User Interface functions
              +-x---x---x---x---x-+-x-+   )
              |                       |   |
              |        Library        |   |- Core DPKGv2 Library
              |                       |   |
              +---+---+---+---+---+---+   )
                   ||| ||| ||| |||
                   ooo ooo ooo ooo        )- DPKGv2 or 3rd-party, Modules


     DPKGv2 Design and Technical Specifications

     Ben Collins <bcollins@debian.org>
     Wichert Akkerman <wichert@linux.com>

     $Id: dpkg2-spec.sgml,v 1.26 1999/07/16 16:41:49 wichert Exp $

Attachment: pgp4XMoMA7whD.pgp
Description: PGP signature

Reply to: