From debian-devel@pixar.com Tue May 31 12:16:42 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
id AA21280; Tue, 31 May 94 12:16:33 EST
Received: from mongo by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0q8XKF-0006aha; Tue, 31 May 94 10:10 PDT
Date: Tue, 31 May 94 10:10 PDT
Message-Id: <9405311708.AA01392@thokk.cs.cornell.edu>
Errors-To: bruce@pixar.com
Reply-To: mdw@cs.cornell.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdw@cs.cornell.edu (Matt Welsh)
To: debian-devel@pixar.com
Subject: Binary Package and Installation Tools Spec
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO
Here is the preliminary version of the binary package and installation
tools (dpkg et. al.) spec. Ian is working on implementing dpkg as
described below, and I'll soon start work on the front-end to handle
configuration.
Hopefully this will get us on the road to distributing configurable
binary packages. I'd like this spec to be fairly stable so that
package maintainers can depend on it.
Please send any comments to the debian-devel list... preferably Cc:
to < mdw@cs.cornell.edu> as well---which will ensure a speedier reply.
This is not carved in stone, so I need your feedback ASAP.
Ian, can you place this in the `standards' directory on sunsite?
Thanks.
mdw
--
Debian GNU/Linux Binary Package and Installation Tools specification
Matt Welsh, < mdw@sunsite.unc.edu>
v0.2, 31 May 1994
0. Introduction
This specification describes the format of `.deb' binary packages
for the Debian GNU/Linux distribution. It also describes the various
installation tools that manipulate packages; this includes `dpkg' and
the dpkg front-end.
All Debian package maintainers should follow the binary package
specification contained herein; given the description of dpkg and
related tools, you will know how binary packages will be installed,
upgraded, and configured. These subjects are intimately tied together,
which is why there is one specification for all of them.
Please see the Debian Source Package Guidelines for information concerning
the creation of Debian Source Packages (from which Binary Packages are
built).
Note: This is a PRELIMINARY specification. It has not been implemented yet.
Therefore, members of the Debian development group should make comments,
suggestions, and outright corrections to it before we begin to implement
dpkg and the install tools as described here. Critique should be mailed
to myself (mdw@sunsite.unc.edu) and Ian Murdock (imurdock@gnu.ai.mit.edu).
1. Binary Package Format
A Debian Binary Package (hereafter refered to as a `package') consists
of two parts: A set of files which make up the software package in
question, and configuration/installation information. This configuration
information will consist of package-specific installation and configuration
scripts; information on the origin, version, and maintainer of the package;
information on package dependencies and conflicts, and so forth.
Much of the rationale for the following package format specification is
based on the installation tools, which are described in the next section.
If the reasoning behind a particular aspect of this format is not clear,
section 2, below, should clear up any confusion.
Debian packages will be stored as a single gzipped tar file. Canonically,
package filenames will end in the extension `.deb', although the installation
tools will not depend at all on the package filenames.
1.1 Package contents
The package tar file should contain all files included in the software
package, archived from the root directory (`/'). The installation tools
will extract packages from the root directory of the system, so everything
should be in the right place within the package tar file. In addition, all
file permissions and ownership information of files in the package should
be correct as they are archived. `tar' will be used to extract package
files, which will set the permissions and ownership of the files as they
are extracted.
The following guidelines should be followed for file layout and permissions
within the binary package:
* The location of installed files must follow the Linux Filesystem
Standard. The latest version of this document can be found
alongside this Debian source package guidelines. Specific
questions about following the filesystem standard can be
addressed to Daniel Quinlan < quinlan@spectrum.cs.bucknell.edu>.
* All directories should be mode 755, with the exception of
special "system" directories that need to be another mode. The
ownership of the directory should be consistent with its mode;
if a directory is mode 775, then it should be owned by the group
that needs write access to it. Use common sense in assigning
permissions and ownerships to directories, and make sure that
what is done is secure if it is not the standard configuration.
* In general, normal binaries should be mode 755 and owned by
root.bin. If there is a good reason to use a different mode
or ownership, then feel free to do so, but do try to be as
consistent as possible with the rest of the system.
* Setuid/setgid binaries should be mode 4711/2711 and owned by
the appropriate user/group. For security reasons, please do
not make setuid/setgid binaries mode 4755/2755.
* Library files should generally be installed as mode 644 and
owner root.root; however, if the package requires different
permissions or ownerships to function correctly, then they
should obviously be used instead.
* Manual pages should be mode 644 and owned by root.root. The
nroff source must be installed. Do not install a pre-formatted
catman page.
* Man pages should be edited to reflect the Debian package. For
example, references of /etc/utmp should be changed to
/var/adm/utmp. Documentation really should be consistent with
the system.
* Info documents should be mode 644 and `gzipped' when installed.
* Any other documentation that comes with the package should be
installed at the discretion of the package maintainer. Text
documentation should be mode 644, `gzipped' and installed to
/usr/doc. If a subdirectory of /usr/doc is warranted, then
please feel free to create one.
* Any example files (for example, sample configuration files)
should be placed in /usr/doc/examples. If the file is normally
a "hidden" file, such as `.emacs', then please call it
`dot.emacs' to avoid confusion.
* All symbolic links should be relative, not absolute. Absolute
links, in general, cause problems when a filesystem is not
mounted where it ``normally'' resides (for example, when mounted
via NFS). In certain cases, however, relative links may also
cause similar problems (for example, if /usr is mounted on
/foo/bar, and /foo/bar/spool is a link to ../spool it will not
find it); in this case, feel free to use absolute links, but they
should be used only when necessary. I have generally made links
into /etc and /var absolute and all other links relative. There
may be other cases in which absolute links are necessary.
1.2 Configuration information
In addition to the contents of the software package, packages will also
contain configuration information, stored in the directory `/.DEBIAN'
at the root of the tar file. Files within the .DEBIAN/ directory are:
.DEBIAN/control Master package configuration file
.DEBIAN/preinst.sh Package pre-installation script
.DEBIAN/postinst.sh Package post-installation script
.DEBIAN/prerm.sh Package pre-removal script
.DEBIAN/postrm.sh Package post-removal script
Of these, only .DEBIAN/control is required. The various installation
scripts will only be used if they are present.
1.2.1 Control file format
The .DEBIAN/control file contains a number of fields. Each field begins
with a tag, such as `PACKAGE' or `VERSION' (case insensitive), followed
by a colon, and the body of the field. Fields are delimited only by
field tags. In other words, field text may be multiple lines in length,
but the installation tools will generally join lines when processing
the body of the field.
The required fields in the control file are the following:
PACKAGE: < Short name of package>
VERSION: < Version number>
MAINTAINER: < Name and e-mail address of package maintainer>
DESCRIPTION: < Description of package>
There is but one restriction on the format of control file fields:
The value of `PACKAGE' will be used to generate filenames by the
installation tools, and therefore should be a valid filename prefix
(i.e., no embedded slashes), and not contain any whitespace.
The option fields in the control file are the following:
DEPENDS: < Short names of prerequisite packages>
RECOMMENDED: < Short names of related, recommended packages>
OPTIONAL: < Short names of related, optional packages>
CONFLICTS: < Short names of packages which conflict with this one>
An example of a .DEBIAN/control file would be:
PACKAGE: emacs
VERSION: 19.22
MAINTAINER: Daniel Quinlan < quinlan@bucknell.edu>
DESCRIPTION: The extensible, customizable, self-documenting,
real-time display editor
DEPENDS: emcsmisc, emcselc1, emcselc2
RECOMMENDED: emcselz1, emcselz2, emcsinfo
OPTIONAL: emcsetc
CONFLICTS: emacs_nox
In this case, the `emacs' package will contain the binary with X support,
and `emacs_nox' contains the binary without X support. The control
file for `emacs_nox' would contain a `CONFLICTS: emacs' line accordingly.
1.2.2 Installation script format
The files `preinst.sh', `postinst.sh', `prerm.sh', and `postrm.sh' are
optional (bash or perl) scripts contained within the .DEBIAN directory
in the package. As the names imply, if these scripts exist they will
be executed before installing the package, after installation, before
package removal, and after removal, respectively.
These scripts can be used to perform any site-specific package configuration.
Because the scripts will be exectued by the dpkg front-end, it is guaranteed
that the scripts will be executed interactively.
1.3 Package configuration
Apart from the package-specific configuration scripts, above, the
installation tools will perform semi-automatic package configuration
for files in the package with the extension `.DIST' in the filenames.
This configuration will ensure that package-specific configuration files
are not overwritten when a package is upgraded, unless the user wishes
the installation tools to do so.
Typically, files named `*.DIST' are package-specific configuration files,
which (according to the Linux Filesystem Standard) are stored in /etc.
For example, the `sendmail' package may contain the file
`/etc/sendmail.cf.DIST'. Only those files with the `.DIST' filename
extension will be updated intelligently when a package is upgraded; all
other files in the package will be overwritten by the upgrade process.
The exact method for .DIST file update is covered in section 2, below.
When creating a Debian Binary Package, you should name any files within
the package that should NOT be overwritten by an upgrade with the
`.DIST' filename extenion. Generally, this will include all package-specific
configuration files (the files in the actual software package, not those
in the `/.DEBIAN' directory).
Note that the `postinst.sh' script will be run after the package is
installed, but before *.DIST files are updated by the installation tools.
Therefore, if `postinst.sh' needs to modify any package configuration
files, it should operate on `*.DIST'.
1.4 Creating a Debian Binary Package
Packages are merely gzipped tar files with the embedded .DEBIAN directory.
Therefore, the canonical way to create a binary package is to follow
these steps:
1) Install the entire package in a clean directory tree on the
source system, (for example, /usr/src/root_dir), ensuring that
file permissions and ownerships are correct;
2) Create the `.DEBIAN' directory at the root of this tree;
3) Within `.DEBIAN', create the files `control', as well as
(optionally) `preinst.sh', `postinst.sh', `prerm.sh',
and `postrm.sh';
4) Issue a command such as:
cd /usr/src/root_dir; tar cf - | gzip -9c > ../foo.deb
To create the package `foo.deb' from the contents of the
directory `root_dir'.
2. Package Installation Tools
The Debian package installation tools will consist of two applications:
`dpkg', which is responsible for package installation, removal, and
sanity-checking; and a dpkg front-end, which is responsible for
locating and selecting packages to install, as well as package configuration.
Note that dpkg does nothing about package configuration; it is only
responsible for installing the package software on the system. The
front-end (which can be given a number of interfaces) will select packages,
invoke dpkg for each, and handle all package configuration issues.
One of the reasons for this is that the front-end should handle all
interactive use of the installation tools. In addition, the user may wish
to install many software packages at one time, but delay configuration
until the installation process has been completed. Making dpkg and the
front-end independent of one another is the best way to achieve this.
Note that dpkg will rarely be used alone; nearly all packages will
require some kind of configuration. For those who wish to do things
`by hand', one of the available front-ends for dpkg will be a script
that invokes dpkg to install a named package, and immediately configure
it. Of course, a number of smarter, more interface-laden front-ends
will be available as well, both for terminal and X-based environments.
2.1 dpkg
The format of the dpkg command is as follows:
dpkg [ -i | --install ] < package>
dpkg [ -r | --remove ] < package>
dpkg [ -l | --list ]
dpkg [ -c | --contents ] [ -d | --describe ] [ -v | --version]
< package>
dpkg [ -s | --search ] < regexp>
dpkg [ -s | --extract ] < package> [ < directory> ]
Where < package> is the pathname of a Debian package file, and
< regexp> is a regular expression.
Invoking dpkg with the `-i' option will install the named < package> on
the system. Essentially this consists of:
1) Determining if another version of this package is already
installed, and if so, remove it;
2) Unpacking the contents of the package from the system root
directory;
3) Moving the contents of the /.DEBIAN directory (created by
unpacking the tar file) to the appropriate location (see
below).
4) Generate a list of files installed from the package (see below).
Note that the directory /.DEBIAN will be created by the installation
procedure, and subsequently moved to another location. Therefore,
dpkg will exit with an error message if .DEBIAN already exists (which
means that another dpkg process is running on this system, or a
previous dpkg crashed before making it to step (3)).
dpkg will move the contents of /.DEBIAN to /var/adm/dpkg as follows:
* /.DEBIAN/control will be moved to /var/adm/dpkg/< package>.control,
where < package> is the name of the package given in the control
file (not determined from the package filename).
* The installation scripts, /.DEBIAN/*.sh, will be moved to
/var/adm/dpkg/< package>.*.sh.
During the installation procedure, dpkg will generate a list of files
in the package, and store it in the file /var/adm/dpkg/< package>.list.
Invoking dpkg with the `-r' option will remove the named package, if it
has been installed on the system. Essentially this consists of deleting
all files on the system from the corresponding filelist in
/var/adm/dpkg/< package>.list. This will also delete all information
about the package in /var/adm/dpkg.
Invoking dpkg with the `-l' option will list all packages installed on
the system. It will print a short, one-line summary of each package, such as:
Name Version Install date
--------------- --------------- -------------
groff 1.0.9 13 May 1994
emacs 18.59 23 Aug 1993
Installation dates can be gathered from the ctime of the corresponding
files in /var/adm/dpkg, or amended to the control file at installation
time.
The `-c', `-v', and `-d' options give information about packages
which match the given regular expression. The named packages may be
either installed, in which case < package> specifies an installed
package name, or uninstalled, in which case < package> is a pathname
to a (not yet installed) package.
`-c' prints the contents of the package, in ls -adl format. `-v' prints
version and maintainer information for the package. `-d' prints the
description of the package from the control file.
The `-s' option searches for the named file(s) (given by the regular
expression < regexp>) in all installed packages, and prints the names
of the package(s) in which it is found. For example, `dpkg -s "?dit*"'
might print:
groff
xditview
The regular expression is matched against the installed-package filelists
in /var/adm/dpkg/*.list.
The `-e' option will extract the package control directory .DEBIAN from
the named < package>, and place it in the named < directory> (or
`./.DEBIAN' if no < directory> is specified). For example,m
dpkg -e foo.deb /tmp/foo-information
will copy `/.DEBIAN/*' from the package to `/tmp/foo-information'.
The directory `.DEBIAN' will _not_ be created beneath the named
< directory>.
2.2 dpkg Front-end
There will be several front-ends to dpkg available; they will provide
a friendly user interface for finding and selecting packages to
install/remove, as well as take care of package configuration.
For example, when the user wishes to install a set of packages at
one time, dpkg will be invoked for each package, but the package-specific
installation scripts (.DEBIAN/preinst.sh et. al.) will be executed in
one batch for all packages.
When installing packages, the front-end will handle package configuration
in the following way:
1) Before the package has been installed (using dpkg), the
contents of the /.DEBIAN directory will be extracted from
the package, and saved in a temporary directory.
2) If /.DEBIAN/preinst.sh exists, it will be executed;
3) dpkg will be invoked to install the package;
4) If /.DEBIAN/postinst.sh exists, it will be executed;
5) Files with the .DIST filename extension will be handled
in the following way. For all *.DIST in the newly-installed
package,
* If no corresponding < file> exists for < file>.DIST, rename
< file>.DIST to < file>.
* If < file>.DIST is equivalent to < file>, delete < file>.DIST.
* If < file>.DIST differs from < file>, give the user the
following options:
a) Allow the user to update manually: Rename
< file>.DIST to < file>.dist.new.
b) Use newer configuration file: Rename < file>.DIST to
< file>; remove < file>.dist and < file>.dist.new if
they exist.
c) Use original configuration file: Rename < file>.DIST
to < file>.dist.
(NB Actually, (a) and (b) are somewhat equivalent. Perhaps
we should provide only two options.)
The front-end will also be able to select user defaults for
*.DIST updates, and so forth.
6) Remove the front-end's temporary copy of /.DEBIAN files.
(Note: I don't like having two copies of /.DEBIAN around, but I don't see any
of any way around it at this point. Of course the front-end will move
/.DEBIAN out of the way before dpkg creates it.)
The front end will handle package removal in the following way:
1) Execute /var/adm/dpkg/< package>.prerm.sh, if it exists;
2) Save a copy of /var/adm/dpkg/< package>.postrm.sh, if it
exists (as dpkg will delete all files from /var/adm/dpkg
corresponding to this package);
3) Invoke dpkg to remove the package from the system;
4) Execute saved copy of /var/adm/dpkg/< package>.postrm.sh, if
it exists.
3. Comments
Please send your comments on this specification to M. Welsh
(mdw@sunsite.unc.edu) and Ian Murdock (imurdock@gnu.ai.mit.edu).
This specification is necessarily vague, because many of the details
of implementation have not been determined yet. However, most of
the major issues should be presented here, and I welcome your
suggestions and ideas.
Once this specification is complete we will be able to produce these
tools, and give package maintainers something solid to go by. I'd like
for this to be as long-term as possible, so that maintainers don't
have to modify their package distribution as the spec changes. Therefore,
if you can think of potential future extensions of this specification,
now is the time to bring them up.
From debian-devel@pixar.com Tue May 31 22:50:14 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
id AA28640; Tue, 31 May 94 22:50:11 EST
Received: from mongo by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0q8hDQ-0007oma; Tue, 31 May 94 20:43 PDT
Date: Tue, 31 May 94 20:43 PDT
Message-Id: <199406010342.AA08295@SunSITE.Unc.EDU>
Errors-To: bruce@pixar.com
Reply-To: johnsonm@sunsite.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: ""Michael K. Johnson"" < johnsonm@sunsite.unc.edu>
To: debian-devel@pixar.com
Subject: Re: Binary Package and Installation Tools Spec
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO
Matt Welsh writes:
>In addition to the contents of the software package, packages will also
>contain configuration information, stored in the directory `/.DEBIAN'
>at the root of the tar file. Files within the .DEBIAN/ directory are:
> .DEBIAN/control Master package configuration file
> .DEBIAN/preinst.sh Package pre-installation script
> .DEBIAN/postinst.sh Package post-installation script
> .DEBIAN/prerm.sh Package pre-removal script
> .DEBIAN/postrm.sh Package post-removal script
>
>Of these, only .DEBIAN/control is required. The various installation
>scripts will only be used if they are present.
May I suggest /tmp/.DEBIAN/ instead? You later say that you will be
creating and deleting the directory for every package, and that's not
necessarily nice to do in /.
>1.4 Creating a Debian Binary Package
>
>Packages are merely gzipped tar files with the embedded .DEBIAN directory.
>Therefore, the canonical way to create a binary package is to follow
>these steps:
> 1) Install the entire package in a clean directory tree on the
> source system, (for example, /usr/src/root_dir), ensuring that
> file permissions and ownerships are correct;
> 2) Create the `.DEBIAN' directory at the root of this tree;
> 3) Within `.DEBIAN', create the files `control', as well as
> (optionally) `preinst.sh', `postinst.sh', `prerm.sh',
> and `postrm.sh';
> 4) Issue a command such as:
> cd /usr/src/root_dir; tar cf - | gzip -9c > ../foo.deb
Please consider suggesting this instead:
cd /usr/src/root_dir; tar cf - tmp/.DEBIAN . | gzip -9c > ../foo.deb
(Or without the tmp/ if you don't take my other suggestion)
This will ensure that the metafiles are at the beginning of the
archive so that the entire archive doesn't have to be searched to pull
them out at the beginning.
Of course, tar won't let you stop at the first version of the file
anyway, so I guess that with this scheme, you will have to run the
whole file through twice anyway. This is a serious problem, IMHO.
Also, the way you are talking about making the packages doesn't really
facilitate making binary packages from source packages easily. Very
frankly, the SYSV package scheme works better for that, *because it
uses cpio*. You can specify the source file for each file in the
archive (unfortunately, you have to, but there are tools for
automating it, so it isn't so hard), and you don't have to create a
special different pseudo-root direcotory for every sub-package. It
also allows for multi-volume packages, which are important when
binaries get large...
I know we don't like cpio and all that (heck, I don't know if I even
have it installed on my machine...) but it does allow more flexible
placement of files in archives.
Matt and Ian, I will gladly buy one or both of you the specification
for SYSV packages. It isn't perfect, but you might glean some ideas
from it that may save you and others grief in the long run. Tell me
if you want it.
michaelkjohnson
From debian-devel@pixar.com Wed Jun 1 00:02:13 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
id AA28929; Wed, 1 Jun 94 00:02:09 EST
Received: from mongo by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0q8iL5-0007oha; Tue, 31 May 94 21:55 PDT
Date: Tue, 31 May 94 21:55 PDT
Message-Id: <9406010454.AA19358@spectrum.cs.bucknell.edu>
Errors-To: bruce@pixar.com
Reply-To: quinlan@spectrum.cs.bucknell.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: quinlan@spectrum.cs.bucknell.edu (Daniel Quinlan)
To: debian-devel@pixar.com
Subject: Re: Binary Package and Installation Tools Spec
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO
Michael K Johnson < johnsonm@sunsite.unc.edu> writes:
> Also, the way you are talking about making the packages doesn't
> really facilitate making binary packages from source packages
> easily. Very frankly, the SYSV package scheme works better for
> that, *because it uses cpio*. [...]
I should have asked this a long time ago, but I never really
considered it until now. Is there any possible way that we can extend
the specification for SYSV packaging? I think that if it is possible,
it *may* be worth the necessary extra effort.
Dan
From debian-devel@pixar.com Wed Jun 1 12:25:18 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
id AA04813; Wed, 1 Jun 94 12:25:15 EST
Received: from mongo by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0q8twB-0006fVa; Wed, 1 Jun 94 10:18 PDT
Date: Wed, 1 Jun 94 10:18 PDT
Message-Id: <199406011713.AA17852@SunSITE.Unc.EDU>
Errors-To: bruce@pixar.com
Reply-To: mdw@sunsite.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdw@sunsite.unc.edu (Matt Welsh)
To: debian-devel@pixar.com
Subject: Re: Binary Package and Installation Tools Spec
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO
quinlan@spectrum.cs.bucknell.edu (Daniel Quinlan) writes:
>
> I should have asked this a long time ago, but I never really
> considered it until now. Is there any possible way that we can extend
> the specification for SYSV packaging? I think that if it is possible,
> it *may* be worth the necessary extra effort.
I need to look more closely at the SYSV packaging tools. Is there some
reason why we wouldn't want to use the SYSV packaging tools directly?
mdw
From debian-devel@pixar.com Wed Jun 1 13:49:23 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
id AA05358; Wed, 1 Jun 94 13:49:17 EST
Received: from mongo by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0q8vFV-0006b1a; Wed, 1 Jun 94 11:42 PDT
Date: Wed, 1 Jun 94 11:42 PDT
Message-Id: < m0q8tal-0000MrC@firefly.firefly.com>
Errors-To: bruce@pixar.com
Reply-To: dhs%firefly@uu5.psi.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: dhs%firefly@uu5.psi.com (David H. Silber)
To: debian-devel@pixar.com
Subject: Re: Binary Package and Installation Tools Spec
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO
Regarding the "Binary Package and Installation Tools Spec", I have two
points to make. The first is probably just a typo:
> 2.2 dpkg Front-end
> [ Other details removed... ]
>
> 5) Files with the .DIST filename extension will be handled
>
> [ Skipped some details. ]
>
> * If < file>.DIST differs from < file>, give the user the
> following options:
> a) Allow the user to update manually: Rename
> < file>.DIST to < file>.dist.new.
> b) Use newer configuration file: Rename < file>.DIST to
> < file>; remove < file>.dist and < file>.dist.new if
> they exist.
> c) Use original configuration file: Rename < file>.DIST
> to < file>.dist.
> (NB Actually, (a) and (b) are somewhat equivalent. Perhaps
> we should provide only two options.)
The `NB' makes no sense. Perhaps it is (a) & (c) which are "somewhat
equivalent"?
My second point is more of a usability problem. We have scripts with names
specified as follows:
> 1.2 Configuration information
>
> In addition to the contents of the software package, packages will also
> contain configuration information, stored in the directory `/.DEBIAN'
> at the root of the tar file. Files within the .DEBIAN/ directory are:
> .DEBIAN/control Master package configuration file
> .DEBIAN/preinst.sh Package pre-installation script
> .DEBIAN/postinst.sh Package post-installation script
> .DEBIAN/prerm.sh Package pre-removal script
> .DEBIAN/postrm.sh Package post-removal script
Please, could we drop the `.sh'? We know what these files do. If there
is ever any question about their contents, `file' will report "commands
text" or "a /bin/perl script" (assuming that the first line specifies
this). All the `.sh' does is clutter up the list of files. If more
descriptive names are desired, how about `preinstall', `postinstall',
`preremove' and `postremove'? I currently support a large legacy system
which uses a similar naming convention for its shell scripts. It really
does not add any meaningfull information.
Other than these two points, this seems to be fairly well thought out.
Since I am home sick from work today, I should be able to put together the
`bc' package according to the specs (as published). I realize that this
means that I might have to redo it later, but that's life. :-)
--
---------------------
--------------------- | Firefly Project | ---------------------
| David H. Silber | --------------------- | dhs@firefly.com |
--------------------- ---------------------
-------------------------------
| Writing perfect software |
| for an imperfect world. |
-------------------------------
From debian-devel@pixar.com Thu Jun 2 09:06:36 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
id AA13766; Thu, 2 Jun 94 09:06:32 EST
Received: from mongo by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0q9DJP-00089xa; Thu, 2 Jun 94 06:59 PDT
Date: Thu, 2 Jun 94 06:59 PDT
Message-Id: < m0q9CBh-0000YaC@debra>
Errors-To: bruce@pixar.com
Reply-To: imurdock@murdoc.pnet.msen.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: imurdock@murdoc.pnet.msen.com (Ian Murdock)
To: debian-devel@pixar.com
Subject: Re: Binary Package and Installation Tools Spec
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO
Matt Welsh writes:
""Michael K. Johnson"" < johnsonm@merengue.oit.unc.edu> writes:
>
> Matt Welsh writes:
> >I need to look more closely at the SYSV packaging tools. Is there some
> >reason why we wouldn't want to use the SYSV packaging tools directly?
>
> We'd have to re-write them... Or at least re-write equivalent
> functionality. Like I say, do you want a copy of the spec?
Let me dig for it around here, and get back to you if nothing turns
up.
If we decide to take this route, there has already been partial work
on SYSV-compatible pkg* utilities by two different groups. From what
I understand, the projects have died due to lack of interest, but we
could use their work as a starting point.
I agree with Matt that we need to implement something soon. Future
compatibility with SYSV pkg* would be nice, but I don't think we can
afford to spend several months on it now.
From debian-devel@pixar.com Thu Jun 2 11:14:46 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
id AA14937; Thu, 2 Jun 94 11:14:35 EST
Received: from mongo by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0q9FJK-0008n8a; Thu, 2 Jun 94 09:08 PDT
Date: Thu, 2 Jun 94 09:08 PDT
Message-Id: < m0q9CBW-0002dGC.ijackson@nyx.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: Re: Binary Package and Installation Tools Spec
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO
(Sorry, this message is rather long, but it's probably better than
several somewhat shorter ones ...)
Matt Welsh writes:
> * All directories should be mode 755, with the exception of
> special "system" directories that need to be another mode. The
> ownership of the directory should be consistent with its mode;
> if a directory is mode 775, then it should be owned by the group
> that needs write access to it. Use common sense in assigning
> permissions and ownerships to directories, and make sure that
> what is done is secure if it is not the standard configuration.
You've forgotten the setgid bit - almost any directory which is
group-writeable should have its subdirectories remain writeable by the
same group. Hence, 2775, 2755 or 755, but not 0775.
> * Info documents should be mode 644 and `gzipped' when installed.
What about updating the `dir' file ? Is that going to be done
automatically by dpkg or the front-end if it spots files that are
placed in /usr/info ? If someone writes a spec for what
`install-info' or some sister program should do I'll write it.
Incidentally, I'm still waiting for someone with a package with
multi-part Info documentation to send me a Makefile fragment to show
me how install-info is used in this context. Help !
> * Any other documentation that comes with the package should be
> installed at the discretion of the package maintainer. Text
> documentation should be mode 644, `gzipped' and installed to
> /usr/doc. If a subdirectory of /usr/doc is warranted, then
> please feel free to create one.
What about /usr/doc/copyright ? If you like the idea we should
require that every package install a file in there. The file should
contain the copying conditions and any authorship notices required by
those conditions. If a package is public domain it should probably
say something like `This package is public domain - ie it is not
copyrighted. Note however that there is a compilation copyright on
the whole Debian system which requires you to abide by the terms of
the GNU General Public Licence when distributing Debian.'.
> 1.2 Configuration information [...]
> 1.2.1 Control file format [...]
>
> There is but one restriction on the format of control file fields:
> The value of `PACKAGE' will be used to generate filenames by the
> installation tools, and therefore should be a valid filename prefix
> (i.e., no embedded slashes), and not contain any whitespace.
Perhaps more stringent requirements would be a good idea - for
example, that package names should match the regexp
[A-Za-z][-A-Za-z0-9]{0,7} (do we want to use `_'s or `-'s ? We should
specify which, for consistency, and I'd plump for `-'.)
> 1.2.2 Installation script format
>
> The files `preinst.sh', `postinst.sh', `prerm.sh', and `postrm.sh' are
> optional (bash or perl) scripts [...]
Clearly they should not be called *.sh if they can be other than sh
scripts. Also, you should require that they have an appropriate #!
line, one of:
#!/bin/sh
#!/usr/bin/perl
(someone writing scripts should take this for granted, really, but
people can be amazingly stupid - Solaris 2's /bin/false doesn't work
if your shell is something like rc, because it doesn't start #!)
> 1.3 Package configuration [...; see my comments below]
> 2. Package Installation Tools [...]
> 2.1 dpkg [...]
> 2.2 dpkg Front-end [...]
>
> When installing packages, the front-end will handle package configuration
> in the following way: [steps 1-4 deleted]
>
> 5) Files with the .DIST filename extension will be handled
> in the following way. For all *.DIST in the newly-installed
> package,
> * If no corresponding < file> exists for < file>.DIST, rename
> < file>.DIST to < file>.
> * If < file>.DIST is equivalent to < file>, delete < file>.DIST.
> * If .DIST differs from < file>, give the user the
> following options:
> a) Allow the user to update manually: Rename
> < file>.DIST to < file>.dist.new.
> b) Use newer configuration file: Rename < file>.DIST to
> < file>; remove < file>.dist and < file>.dist.new if
> they exist.
> c) Use original configuration file: Rename < file>.DIST
> to < file>.dist.
You've removed the note that said that if the *.DIST file has vanished
in the meantime (ie, it was deleted by the post-installation script)
then the configuration program should silently do nothing.
You have also made a subtle change to my proposal that has an
undesirable effect in the case where a system administrator wishes to
remove a configuration file completely and not have it put back at
every installation - this is a requirement because many packages treat
absence of certain files specially (cron.deny/cron.allow for example).
In my scheme this is handled by having *.dist present but * absent.
Specifically, the equivalence test should test for equivalence with
*.dist if it exists before looking for *. If *.dist exists and is the
same as *.DIST the latter should be deleted regardless of the presence
or contents of *.
You have removed the comment in my proposal which notes that for the
purposes of testing equivalence two symlinks are equivalent if they
point to the same file, and that a symlink is never equivalent to a
plain file. This is required because the file that a symlink points
to is outside the control of our scheme, and default configuration
files may well be links to /usr/lib/foobly/default.conf or whatever.
I'm not sure what to do about educating the user to tell them that to
reconfigure they should remove the symlink and create a plain file
instead, rather than editing the default file through the link. One
possibility is to disallow the use of symlinks to other files in /etc
(which would do away with the need to say how they're handled), but
that seems like a nasty restriction and makes /usr/etc difficult.
I see you have removed my proposals concerning *.MSG - fine, that
could be thought of as featuritis, and can be handled by postinstall.
> (NB Actually, (a) and (b) are somewhat equivalent. Perhaps
> we should provide only two options.)
I don't understand this. If any two options were similar they would
be (a) and (c). However, (a) and (c) are different in a crucial way:
if the user selects (a) and does nothing more then at the next upgrade
they will be prompted again and reminded that they forgot to fix it.
If they select (c) then they will not be bothered again unless the
distributed version of the file changes. This should be made clear
both here in the packaging guidelines and in the prompts given to the
user.
> (Note: I don't like having two copies of /.DEBIAN around, but I don't see any
> of any way around it at this point. Of course the front-end will move
> /.DEBIAN out of the way before dpkg creates it.)
You do know about GNU tar's --exclude option ? That should allow you
to avoid actually unpacking the files from the tarfile in /.DEBIAN.
> The front end will handle package removal in the following way:
>
> 1) Execute /var/adm/dpkg/< package>.prerm.sh, if it exists;
> 2) Save a copy of /var/adm/dpkg/< package>.postrm.sh, if it
> exists (as dpkg will delete all files from /var/adm/dpkg
> corresponding to this package);
> 3) Invoke dpkg to remove the package from the system;
> 4) Execute saved copy of /var/adm/dpkg/< package>.postrm.sh, if
> it exists.
What about removing any *.dist and *.dist.new files ?
Michael K. Johnson writes:
> May I suggest /tmp/.DEBIAN/ instead? You later say that you will be
> creating and deleting the directory for every package, and that's not
> necessarily nice to do in /.
See my comments above re --exclude.
> >1.4 Creating a Debian Binary Package
> Please consider suggesting this instead:
> cd /usr/src/root_dir; tar cf - tmp/.DEBIAN . | gzip -9c > ../foo.deb
> (Or without the tmp/ if you don't take my other suggestion)
> This will ensure that the metafiles are at the beginning of the
> archive so that the entire archive doesn't have to be searched to pull
> them out at the beginning.
No, this is a bad idea because it will put tmp/.DEBIAN or whatever in
twice. What you should do is something like
GZIP=-9v tar -f foo.deb -C /usr/src/root-dir -zvvc .DEBIAN *
so that the .DEBIAN directory is only included once. This assumes
that you don't have directories starting with `.' under /. This seems
like a reasonable assumption ...
> Of course, tar won't let you stop at the first version of the file
> anyway, so I guess that with this scheme, you will have to run the
> whole file through twice anyway. This is a serious problem, IMHO.
I agree.
David H. Silber writes:
> [...] "a /bin/perl script" [...]
Perl belongs in /usr/bin (whether it is part of the base or not).
Umm, just a moment - if we're doing package installation with Perl we
need to have it on the root partition so that you can do proper
recovery from certain kinds of mistakes. Ummm.
I don't appear to have an up-to-date copy of the source guidelines
here, but I'll probably be posting some more detailed suggestions to
do with making the relationship between them and the binary packages
uniform.
Ian.
From debian-devel@pixar.com Thu Jun 2 10:11:28 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
id AA14371; Thu, 2 Jun 94 10:11:25 EST
Received: from mongo by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0q9EKD-00089sa; Thu, 2 Jun 94 08:04 PDT
Date: Thu, 2 Jun 94 08:04 PDT
Message-Id: <9406021453.AA02013@merengue.oit.unc.edu>
Errors-To: bruce@pixar.com
Reply-To: johnsonm@merengue.oit.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: ""Michael K. Johnson"" < johnsonm@merengue.oit.unc.edu>
To: debian-devel@pixar.com
Subject: Re: Binary Package and Installation Tools Spec
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO
Ian Murdock writes:
>I agree with Matt that we need to implement something soon. Future
>compatibility with SYSV pkg* would be nice, but I don't think we can
>afford to spend several months on it now.
Future compatibility can be assured if we start the package with a
version number. Then we can check the begining of the package to
determine the type if we want to add SYSV package capabilities.
The offer of the specs is for ideas, not to re-write SYSV packaging.
michaelkjohnson
From debian-devel@pixar.com Fri Jun 3 11:19:25 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
id AA01138; Fri, 3 Jun 94 11:19:22 EST
Received: from mongo by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0q9baL-0007rja; Fri, 3 Jun 94 08:55 PDT
Date: Fri, 3 Jun 94 08:55 PDT
Message-Id: <9406031553.AA09408@bb29c.mdd.comm.mot.com>
Errors-To: bruce@pixar.com
Reply-To: mitchell@mdd.comm.mot.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mitchell@mdd.comm.mot.com (Bill Mitchell)
To: debian-devel@pixar.com
Subject: partitioning & base vs installed /usr (was Re: Binary Package [...] Spec)
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO
iwj10@cus.cam.ac.uk (Ian Jackson) writes:
>[...]
> Perl belongs in /usr/bin (whether it is part of the base or not).
> Umm, just a moment - if we're doing package installation with Perl we
> need to have it on the root partition so that you can do proper
> recovery from certain kinds of mistakes. Ummm.
>[...]
Just a half-baked thought here....
How about a minimal (whatever we define minimal to be) functionality
/usr on the root partition in the base system, then reinstall that
minimal /usr stuff (or clone a copy) as the starting point if another
partition is specified for /usr[/whatever] at system setup time.
If another partition is specified for /usr, it'd be mounted on top of the
minimal functionality /usr leaf at post-installation boot. If (for
whatever reason) it didn't get mounted, the user would be left with the
minimal functionality base system /usr as a fallback (unless he chose to
delete its contents on his own to scavenge root partition disk space).
Related topic -- when the setup script offers the user choices about
making partitions and mounting those partitions, the user could really
use some guidance about reasonable figures to use for partition sizes.
From debian-devel@pixar.com Fri Jun 3 11:56:33 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
id AA01515; Fri, 3 Jun 94 11:56:30 EST
Received: from mongo by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0q9cRR-0007qoa; Fri, 3 Jun 94 09:49 PDT
Date: Fri, 3 Jun 94 09:49 PDT
Message-Id: <9406031630.AA09428@bb29c.mdd.comm.mot.com>
Errors-To: bruce@pixar.com
Reply-To: mitchell@mdd.comm.mot.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mitchell@mdd.comm.mot.com (Bill Mitchell)
To: debian-devel@pixar.com
Subject: Partition sizing and arrangement (was Re: partitioning & base vs
installed /usr [...])
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO
I said:
> Related topic -- when the setup script offers the user choices about
> making partitions and mounting those partitions, the user could really
> use some guidance about reasonable figures to use for partition sizes.
.. and arrangement, and usage.
Perhaps something along the lines of the following:
/ | /var | /usr | /usr/X11 | /home | /usr/local |
15-20 MB | 10 MB? | 30 MB? | 30 MB? | whatever | whatever |
/ | | | | | |
/bin/ | | | | | |
/boot/ | | | | | |
/dev/ | | | | | |
/etc/ | | | | | |
/home/---+----------+----------+----------+-joe/ | |
/lib/ | | | | sam/ | |
/mnt/ | | | | sarah/ | |
/proc/ | | | | [...] | |
/root/ | | | | | |
/sbin/ | | | | | |
/tmp/ | | | | | |
/usr/----+----------+-+--------+-X11/ | | |
/var | | +-adm@ | [...] | | |
bin/ | | +-dict/ | | | |
/vmlinuz | | +-doc/ | | | |
+-etc/ | | | |
+-g++-include/ | | |
+-include/ | | |
+-info/ | | | |
+-lib/ | | | |
+-local/-|----------|------------|-bin/ |
+-man/ | . | | doc/ |
+-sbin/ | | | [...] |
+-spool@ | | | |
+-src/ | | | |
+-src/ | | | |
+-tmp@ | | | |
This is first-cut, of course, but I think something like this would be
useful.
From debian-devel@pixar.com Fri Jun 3 13:47:21 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
id AA02437; Fri, 3 Jun 94 13:47:17 EST
Received: from mongo by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0q9eAd-0007saa; Fri, 3 Jun 94 11:40 PDT
Date: Fri, 3 Jun 94 11:40 PDT
Message-Id: < m0q9ejv-0000T4C@firefly.firefly.com>
Errors-To: bruce@pixar.com
Reply-To: dhs%firefly@uu5.psi.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: dhs%firefly@uu5.psi.com (David H. Silber)
To: debian-devel@pixar.com
Subject: Re: Partition sizing and arrangement
(was Re: partitioning & base vs installed /usr [...])
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO
> From pixar.com!debian-devel Fri Jun 3 13:51:08 1994
> Return-Path: < pixar.com!debian-devel>
> Received: by firefly.firefly.com (Linux Smail3.1.28.1 #25)
> id m0q9dOb-0000T3a; Fri, 3 Jun 94 13:51 EDT
> Sender: pixar.com!debian-devel
> Received: from mongo.pixar.com by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet)
via SMTP;
> id AA04526 for debian-mail; Fri, 3 Jun 94 12:49:48 -0400
> Received: from mongo by mongo.pixar.com with smtp
> (Smail3.1.28.1 #15) id m0q9cRH-0007rla; Fri, 3 Jun 94 09:49 PDT
> Date: Fri, 3 Jun 94 09:49 PDT
> Message-Id: <9406031630.AA09428@bb29c.mdd.comm.mot.com>
> Errors-To: bruce@pixar.com
> Reply-To: mitchell@mdd.comm.mot.com
> Originator: debian-devel@pixar.com
> Sender: debian-devel@pixar.com
> Precedence: bulk
> Priority: non-urgent
> From: mitchell@mdd.comm.mot.com (Bill Mitchell)
> To: debian-devel@pixar.com
> Subject: Partition sizing and arrangement
was Re: partitioning & base vs installed /usr [...])
> X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
>
> I said:
>
> > Related topic -- when the setup script offers the user choices about
> > making partitions and mounting those partitions, the user could really
> > use some guidance about reasonable figures to use for partition sizes.
>
> .. and arrangement, and usage.
Two suggestions: (I am assuming that most systems have seperate partitions
for root, /var & /usr and that most or all Debian software would go in these
partitions.)
1) If each package maintainer would update some central database (or
send the figures for the amount of space needed in each partition to a
diskspace document maintainer), a list could be provided and an installer
could add up the space used by the various packages which are to be
installed before partitioning the disk(s).
2) If there was a line in the .DEBIAN/control file called `DISKSPACE:'
with three values representing the amount of room needed in each of root,
/var & /usr partitions, dpkg could perform a sanity check to make sure that
there is enough room /before/ attempting to load the files onto the hard
disk.
3) If both of the above suggestions are used, perhaps eventually we
could automatically extract the numbers for (1) from the control file line
specified in (2).
4) Perhaps the amount of space required to load source distributions
and compile them would also be a valuable figure for those with limited
disk space.
--
---------------------
--------------------- | Firefly Project | ---------------------
| David H. Silber | --------------------- | dhs@firefly.com |
--------------------- ---------------------
-------------------------------
| I was subtle once ... |
| but nobody noticed. |
-------------------------------
From debian-devel@pixar.com Fri Jun 3 20:14:15 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
id AA05408; Fri, 3 Jun 94 20:14:13 EST
Received: from mongo by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0q9kD5-0007tPa; Fri, 3 Jun 94 18:07 PDT
Date: Fri, 3 Jun 94 18:07 PDT
Message-Id: <199406040106.AA09403@SunSITE.Unc.EDU>
Errors-To: bruce@pixar.com
Reply-To: mdw@sunsite.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdw@sunsite.unc.edu (Matt Welsh)
To: debian-devel@pixar.com
Subject: Re: Partition sizing and arrangement
(was Re: partitioning & base vs installed /usr [...])
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO
dhs%firefly@uu5.psi.com (David H. Silber) writes:
> 1) If each package maintainer would update some central database (or
> send the figures for the amount of space needed in each partition to a
> diskspace document maintainer), a list could be provided and an installer
> could add up the space used by the various packages which are to be
> installed before partitioning the disk(s).
Oh, this will be one of the jobs of the Debian front-end. Thank
you for reminding me. It will determine what filesystems you
have an how much space will be required on each due to package
installation. I'll add it to the spec.
You don't need to add lines to the package control file for this;
it can be determined by using dpkg --contents.
In this way we can do totals for the user's filesystems, not just
/, /usr, and /var. For example, someone may have a separate
/usr/local, and the dpkg front-end could determine how much space
is required there.
mdw
From debian-devel@pixar.com Tue Jun 7 08:27:01 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
id AA04629; Tue, 7 Jun 94 08:26:58 EST
Received: from mongo by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0qB14l-0007tYa; Tue, 7 Jun 94 06:20 PDT
Date: Tue, 7 Jun 94 06:20 PDT
Message-Id: < m0qB166-0000Y2C@debra>
Errors-To: bruce@pixar.com
Reply-To: imurdock@murdoc.pnet.msen.com
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: imurdock@murdoc.pnet.msen.com (Ian Murdock)
To: debian-devel@pixar.com
Subject: Disk usage totals
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO
Matt Welsh writes:
dhs%firefly@uu5.psi.com (David H. Silber) writes:
> 1) If each package maintainer would update some central database (or
> send the figures for the amount of space needed in each partition to a
> diskspace document maintainer), a list could be provided and an installer
> could add up the space used by the various packages which are to be
> installed before partitioning the disk(s).
Oh, this will be one of the jobs of the Debian front-end. Thank
you for reminding me. It will determine what filesystems you
have an how much space will be required on each due to package
installation. I'll add it to the spec.
You don't need to add lines to the package control file for this;
it can be determined by using dpkg --contents.
The problem with depending on `dpkg --contents' is that each package
will have to be available to the front-end as it is selected so that
the front-end can read the package for the disk usage summary. This
is entirely reasonable to expect if installing from hard disk or
CD-ROM, but what about floppy disk? The packages themselves will not
necessarily be available for reading.
The user will want to select all packages at once, with disk usage
totals updated per selection, without having to worry about changing
disks. In order to do this, we would have to provide an independent
summary file, or, I suppose, make the feature unavailable to floppy
installations.
Reading disk usage information from the control file presents the same
problem.
From debian-devel@pixar.com Wed Jun 8 01:41:53 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
id AA15703; Wed, 8 Jun 94 01:41:46 EST
Received: from mongo by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0qBHE9-0007tDa; Tue, 7 Jun 94 23:35 PDT
Date: Tue, 7 Jun 94 23:35 PDT
Message-Id: <199406081611.AA10550@adam.com.au>
Errors-To: bruce@pixar.com
Reply-To: steve@adam.com.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Stephen White < steve@adam.com.au>
To: debian-devel@pixar.com
Subject: Re: Disk usage totals
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO
Ian Murdock wrote:
> You don't need to add lines to the package control file for this;
> it can be determined by using dpkg --contents.
>
> The problem with depending on `dpkg --contents' is that each package
> will have to be available to the front-end as it is selected so that
> the front-end can read the package for the disk usage summary.
dpkg could maintain its own information files(s) on various packages. All
the information would be optional, but it could have the following:
Contents listing for total accumulated sizes.
Installation scripts.
Listing of config files to preserve (+ optional description).
Packages can update dpkg with an optional second archive file containing
information. (In a similar fashion to how anti-virus software keeps up to
date)
All the package information can be run through dpkg before beginning
selection (dpkg could come with all the core package information
pre-installed), which solves the informational chicken-and-egg problem.
That's the first half. The next half is to use the *.DebianOLD I proposed
before, with some beefing up.
The information file would list any configuration files in the format:
PRESERVE=/etc/passwd
DESCRIPTION=Listing of users on the system. Not recommended for update.
dpkg would copy any files to preserve to *.DebianOLD. If the user doesn't
want to update the file, then it copies *.DebianOLD back.
If *.DebianOLD already existed while running the install, dpkg wouldn't
copy the file hence aborting the install and re-running isn't a problem.
At this stage, you're probably wondering what the point behind *.DebianOLD
is, since it does the same as *.DIST. The point is two-fold.
1) It keeps all the package control information in one place, instead
of script files here and filename changes over there.
2) It makes Debian packages the same as packages from other distributions,
and dpkg's functioning is independant of what's in the archive. This
has a couple of ramifications:
a) People from other distributions can use Debian packages without
needing dpkg.
b) Debian packages can be created by taking a package from
another distribution and supplying a dpkg installation file.
This is a serious advantage, IMHO.
>From the package maintainer's viewpoint:
Just as simple as the prior *.DIST proposal, except instead of renaming the
file, it is just:
PRESERVE=filename
instead.
--
steve@adam.com.au
From debian-devel@pixar.com Thu Jun 9 09:08:36 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
id AA28547; Thu, 9 Jun 94 09:08:33 EST
Received: from mongo by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0qBkg4-0007uLa; Thu, 9 Jun 94 07:01 PDT
Date: Thu, 9 Jun 94 07:01 PDT
Message-Id: < m0qBhjf-0002dGC.ijackson@nyx.cs.du.edu>
Errors-To: bruce@pixar.com
Reply-To: iwj10@cus.cam.ac.uk
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: iwj10@cus.cam.ac.uk (Ian Jackson)
To: debian-devel@pixar.com
Subject: Re: Disk usage totals
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO
Stephen White writes ("Re: Disk usage totals"):
> That's the first half. The next half is to use the *.DebianOLD I proposed
> before, with some beefing up.
As I have pointed out earlier, this is less robust than renaming the
configuration files.
It is also more work for the package maintainer (renaming files is
easier than editing the control file), and makes it more likely that
they'll get it wrong.
Furthermore, it means that if you try to unpack using plain `tar'
you'll wipe out your existing configuration.
> At this stage, you're probably wondering what the point behind *.DebianOLD
> is, since it does the same as *.DIST. The point is two-fold.
It doesn't - especially when things go slightly wrong. It fails
ungracefully and will probably do so more often.
> 1) It keeps all the package control information in one place, instead
> of script files here and filename changes over there.
There is a substantial amount of package control information in the
tarfile file headers (filenames, etc.). Would you like to bring that
out into the control file too ?
> 2) It makes Debian packages the same as packages from other distributions,
> and dpkg's functioning is independant of what's in the archive. This
> has a couple of ramifications:
>
> a) People from other distributions can use Debian packages without
> needing dpkg.
They can do this better with *.DIST, see above.
> b) Debian packages can be created by taking a package from
> another distribution and supplying a dpkg installation file.
> This is a serious advantage, IMHO.
On the contrary, it is likely to result in packages that don't conform
properly to Debian packaging guidelines. A better idea would be to
unpack the tarfile and repackage it.
In any case, we may well end up using cpio instead of tar.
Ian.
From debian-devel@pixar.com Thu Jun 9 16:33:33 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
id AA04372; Thu, 9 Jun 94 16:33:30 EST
Received: from mongo by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0qBrce-0007tna; Thu, 9 Jun 94 14:26 PDT
Date: Thu, 9 Jun 94 14:26 PDT
Message-Id: <199406100703.AA31975@adam.com.au>
Errors-To: bruce@pixar.com
Reply-To: steve@adam.com.au
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: Stephen White < steve@adam.com.au>
To: debian-devel@pixar.com
Subject: Re: Disk usage totals
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO
Ian Jackson wrote:
> > That's the first half. The next half is to use the *.DebianOLD I proposed
> > before, with some beefing up.
>
> As I have pointed out earlier, this is less robust than renaming the
> configuration files.
Only if you don't use dpkg to unarchive the package. However, every other
Linux package is already like that. It makes more sense to get dpkg to
handle normal packages than be unneccessarily reliant on special archives.
> It is also more work for the package maintainer (renaming files is
> easier than editing the control file), and makes it more likely that
> they'll get it wrong.
Huh? You're not making sense. How difficult do you think it is to create a
file with "CONFIG=/etc/blah" in it? What editor do you use?
> Furthermore, it means that if you try to unpack using plain `tar'
> you'll wipe out your existing configuration.
Ditto for any other package. Try LibC images. Try Slackware packages. Or
packages on Sunsite.
The "rm" command can blast away a system too. There are so many ways of
damaging a system that unpacking a tar archive in the root directory is
insignificant in comparision.
> > At this stage, you're probably wondering what the point behind
> > *.DebianOLD is, since it does the same as *.DIST.
>
> It doesn't - especially when things go slightly wrong. It fails
> ungracefully and will probably do so more often.
Incorrect. It can be aborted, cancelled, power-failured, and re-run at any
time and still keep track of where it was up to.
> There is a substantial amount of package control information in the
> tarfile file headers (filenames, etc.). Would you like to bring that
> out into the control file too ?
That was not part of my proposal and is a seperate issue. The interaction
between tar and dpkg is not affected by my proposal, other than not needing
to look for *.DIST files in tar's output.
However, it would be possible to include some information about how much
room some directories take up so the user can calculate how to partition his
disks. Something along the lines of "SPACE=/usr 356K" is possible. Again, I
stress that this is not part of my proposal, and it remains purely optional
in any case.
The ONLY requirement would be "CONFIG=/etc/blah".
> On the contrary, it is likely to result in packages that don't conform
> properly to Debian packaging guidelines. A better idea would be to
> unpack the tarfile and repackage it.
Debian conforms to FSSTND. Slackware conforms to FSSTND. The packages could
be and should be interchangable. There is a lot of work that we could get
for nothing by using packages from other distributions.
Other distributions could benefit from our work by using our packages. dpkg
could be portable onto any distribution.
And when this could be done with such a minor change as "CONFIG=/etc/blah"
instead of "mv /etc/blah /etc/blah.DIST", then what _logical_ reason
remains as to why we shouldn't?
> In any case, we may well end up using cpio instead of tar.
How is it that you can make major changes like that without sweating, and
yet scream about a minor proposal that has so many benefits?
You may feel that you don't have to explain your actions to me or anyone
else, but while you're in a position where you control the project, you
remain accountable to the developers.
This doesn't mean "I'm tired of explaining to you". It means you should
provide explanations that are logical, coherent, and make sense. Saying
it's harder to make a file with "CONFIG=/etc/blah" in it just doesn't
qualify.
--
steve@adam.com.au
From debian-devel@pixar.com Thu Jun 9 16:44:02 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
id AA04507; Thu, 9 Jun 94 16:43:58 EST
Received: from mongo by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0qBrmm-0007uOa; Thu, 9 Jun 94 14:37 PDT
Date: Thu, 9 Jun 94 14:37 PDT
Message-Id: <9406092136.AA19540@spectrum.cs.bucknell.edu>
Errors-To: bruce@pixar.com
Reply-To: quinlan@spectrum.cs.bucknell.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: quinlan@spectrum.cs.bucknell.edu (Daniel Quinlan)
To: debian-devel@pixar.com
Subject: Enough's enough
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO
Ok, let's all take a deep breath and calm down. This debate is
beginning to get somewhat long-winded and I think a few basic
principles are getting lost in the process.
First, let's all remember that we've agreed that Ian Murdock is the
person who makes the final decisions -- not anyone else.
I also believe that we can safely assume that most people here have
good credentials. If someone truly didn't know what they were talking
about, it would show soon enough. Just because someone is not a
prominent Linux personality, it does not mean that they are less
experienced with Linux. You get the point, I hope.
--
Since I can't even remember who has said what or what it all means
anymore, I'm starting this message from scratch.
I've remained rather quiet in this debate on configuration files, but
I'm ready to have my say in the matter now. I want to see action soon
and not at some distant point when the discussion dies from sheer
exhaustion. I hope to backup my statements with 2 basic principles
that we seem to have forgotten.
(1) We want something yesterday. We want a stable packaging guideline.
I believe that this points the way for putting a list of
configuration files in the control file.
- dpkg can ignore the field for the first release so we
can get something out sooner.
- changes in how the configuration files are handled can be
orchestrated by dpkg without making changes to any one
package.
- packages will not be required to be changed if we change the
handling of the field. Any additional "behavior" can be
put into additional fields.
For example, start with a "CONFIGURATION_FILE:" field. Later,
if some packages need to do something different with a class of
configuration files, we can add a "CONFIGURE_THIS_WAY:" field
or whatever.
- It will also be possible to handle them differently by passing
different options to dpkg. One user my prefer *.old while
another may prefer *.new.
This will let us end the debate NOW and release a new version of
Debian ASAP. It can be *extended* without breaking anything.
(2) We should want to work with the rest of the Linux world,
especially with any packages which are FSSTND/Debian compliant.
A simple software-based solution can allow non-Debian users to use
Debian packages safely. It will also allow Debian users to
utilize non-Debian, but compliant packages with the addition of a
control file.
This will also pave the way for working with other Linux
distributions, instead of against them. dpkg (and related tools)
will be publicly accessible (and GPL'ed) for this purpose.
In addition, allowing a Slackware or SLS devotee to install
Debian's excellent Groff or Emacs package :-) would increase
the popularity of the Debian release as a whole.
Enough said. And yes, this is basically the system that Stephen White
favors if I'm not too mistaken. This system is a win-win situation
for the Debian release and we can implement it quickly and without
further debate.
If there are any problems, we can work them out. Instead of knocking
on any possible shortcomings, I sincerly ask that you try to work with
this scheme, fix any oversights, and get us moving again. Thanks.
Dan
From debian-devel@pixar.com Thu Jun 9 17:09:28 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
id AA04844; Thu, 9 Jun 94 17:09:25 EST
Received: from mongo by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0qBsBP-0007tFa; Thu, 9 Jun 94 15:02 PDT
Date: Thu, 9 Jun 94 15:02 PDT
Message-Id: <9406092200.AA10547@merengue.oit.unc.edu>
Errors-To: bruce@pixar.com
Reply-To: mdw%merengue@merengue.oit.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdw%merengue@merengue.oit.unc.edu (Matt Welsh)
To: debian-devel@pixar.com
Subject: Re: Disk usage totals
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO
Stephen White < steve@adam.com.au> writes:
> Only if you don't use dpkg to unarchive the package. However, every other
> Linux package is already like that. It makes more sense to get dpkg to
> handle normal packages than be unneccessarily reliant on special archives.
You two can stop this inane flamewar now, as I have no intentions
of implementing Steve's proposal (whatever it is---with this gigantic
deluge of e-mail it's difficult to determine what the argument is about).
As far as I can tell, all problems with the current system are solved by
adding an optional CONFIG-SUFFIX: line to the control file. If there are
any other uncovered issues please bring them up with me (personally)
and we'll look into them.
From debian-devel@pixar.com Thu Jun 9 17:11:45 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
id AA04915; Thu, 9 Jun 94 17:11:42 EST
Received: from mongo by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0qBsDc-0007u3a; Thu, 9 Jun 94 15:05 PDT
Date: Thu, 9 Jun 94 15:05 PDT
Message-Id: <9406092202.AA10557@merengue.oit.unc.edu>
Errors-To: bruce@pixar.com
Reply-To: mdw%merengue@merengue.oit.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdw%merengue@merengue.oit.unc.edu (Matt Welsh)
To: debian-devel@pixar.com
Subject: Re: Enough's enough
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO
quinlan@spectrum.cs.bucknell.edu (Daniel Quinlan) writes:
> I believe that this points the way for putting a list of
> configuration files in the control file.
No, you still need to call them *.DIST in order to prevent overwrite
when unpacking the tar file. Therefore I propose CONFIG_SUFFIX
in case the magic pattern *.DIST conflicts with anything.
Unless someone can demonstrate that this won't work, I will be
implementing it.
From debian-devel@pixar.com Thu Jun 9 17:33:51 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
id AA05193; Thu, 9 Jun 94 17:33:49 EST
Received: from mongo by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0qBsZ1-0007tia; Thu, 9 Jun 94 15:27 PDT
Date: Thu, 9 Jun 94 15:27 PDT
Message-Id: <9406092232.AA05172@thorplus.lib.purdue.edu>
Errors-To: bruce@pixar.com
Reply-To: mdickey@thorplus.lib.purdue.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdickey@thorplus.lib.purdue.edu (Mike D.)
To: debian-devel@pixar.com
Subject: Re: Enough's enough
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO
Matt Welsh writes:
>...I have no intentions
>of implementing Steve's proposal (whatever it is
Careful now. We don't want anyone here to get the idea that all of this
discussion was for naught since you had made up your mind some time ago.
If you would've posted this attitude two or three days ago we could've
saved everyone's time. I mean, don't let anyone else stand in the way of
how you are going to build a project for Debian or anything.
>---with this gigantic
>deluge of e-mail it's difficult to determine what the argument is about).
I have asked Steve to make a summary and post it to the list (for
archives reasons and to make sure everyone is clear on it).
>If there are
>any other uncovered issues please bring them up with me (personally)
>and we'll look into them.
This sounds better. It seems as if some people have a problem with being
openminded around here these days... is it the heat of summer? I think
the discussion should be kept on the list, though.
But nothing like this should go on behind closed doors. I learned that
lesson already. If there is something to discuss, use the list. That's
what it's for. However, it's not a playground for flamethrowers.
Mike D.
-------
mdickey@thorplus.lib.purdue.edu Use Debian Linux
From debian-devel@pixar.com Thu Jun 9 17:56:19 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
id AA05322; Thu, 9 Jun 94 17:56:13 EST
Received: from mongo by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0qBsuh-0007txa; Thu, 9 Jun 94 15:49 PDT
Date: Thu, 9 Jun 94 15:49 PDT
Message-Id: <9406092247.AA11018@merengue.oit.unc.edu>
Errors-To: bruce@pixar.com
Reply-To: mdw%merengue@merengue.oit.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdw%merengue@merengue.oit.unc.edu (Matt Welsh)
To: debian-devel@pixar.com
Subject: Re: Enough's enough
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO
mdickey@thorplus.lib.purdue.edu (Mike D.) writes:
> Careful now. We don't want anyone here to get the idea that all of this
> discussion was for naught since you had made up your mind some time ago.
No, I never "made up my mind" and ignored discussion. There are two
issues:
1) I didn't see any good reason to abandon the previous policy;
2) It was difficult to follow Steve's proposal with all of the
ensuing flamage/noise.
If Steve can send me his proposal (personally) we'll discuss it, but
from what I can tell my solution fixes all of those problems.
> If you would've posted this attitude two or three days ago we could've
> saved everyone's time.
I haven't had time to catch up on most of my Debian mail spool
until today. With > 200 pending mail messages on this account,
it's a bit difficult to do...
> But nothing like this should go on behind closed doors.
Well, I think that we've gone over these issues time and time again.
If you want me to be able to implement something or include it in
the spec, talk to me directly. Things will go much more quickly
that way. I agree that initial discussions should be in the open,
but at this point I think it's time for one-on-one.
From debian-devel@pixar.com Thu Jun 9 17:57:50 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
id AA05333; Thu, 9 Jun 94 17:57:48 EST
Received: from mongo by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0qBswE-0007txa; Thu, 9 Jun 94 15:51 PDT
Date: Thu, 9 Jun 94 15:51 PDT
Message-Id: <9406092248.AA11031@merengue.oit.unc.edu>
Errors-To: bruce@pixar.com
Reply-To: johnsonm@merengue.oit.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: ""Michael K. Johnson"" < johnsonm@merengue.oit.unc.edu>
To: debian-devel@pixar.com
Subject: Re: Enough's enough
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO
Matt Welsh writes:
>quinlan@spectrum.cs.bucknell.edu (Daniel Quinlan) writes:
>> I believe that this points the way for putting a list of
>> configuration files in the control file.
>
>No, you still need to call them *.DIST in order to prevent overwrite
>when unpacking the tar file. Therefore I propose CONFIG_SUFFIX
>in case the magic pattern *.DIST conflicts with anything.
You obviously haven't been listening; Steve has very clearly pointed
out why what you have said is not correct.
First you go through all the files that are declared to be config
files, renaming them to something (he suggested .DebianOLD).
*Then* you unpack the archive.
Then you apply *exactly* the same logic to all the config files that
you applied to the DIST files, reversed.
That is, to leave it alone, rename foo.DebianOLD to foo.
>Unless someone can demonstrate that this won't work, I will be
>implementing it.
Steve's solution takes no more programming, and is technically
superior. Yours will work, but is more of a kludge and makes the
CONFIG_SUFFIX kludge also necessary.
michaelkjohnson
From debian-devel@pixar.com Thu Jun 9 18:05:58 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
id AA05353; Thu, 9 Jun 94 18:05:55 EST
Received: from mongo by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0qBt45-0007uQa; Thu, 9 Jun 94 15:59 PDT
Date: Thu, 9 Jun 94 15:59 PDT
Message-Id: <9406092256.AA11325@merengue.oit.unc.edu>
Errors-To: bruce@pixar.com
Reply-To: mdw%merengue@merengue.oit.unc.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdw%merengue@merengue.oit.unc.edu (Matt Welsh)
To: debian-devel@pixar.com
Subject: Re: Enough's enough
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO
""Michael K. Johnson"" < johnsonm@merengue.oit.unc.edu> writes:
> First you go through all the files that are declared to be config
> files, renaming them to something (he suggested .DebianOLD).
Thanks for putting that into a nutshell. Unless anyone can provide
useful objections to this, I'll include something along these lines
in the spec. Please mail me directly. I tried my best to follow
the flamewar, but a great deal of context was lost.
From debian-devel@pixar.com Sun Jun 12 20:29:46 1994
Received: from mongo.pixar.com by thorplus.lib.purdue.edu (4.1/Purdue_CC)
id AA29929; Sun, 12 Jun 94 20:29:42 EST
Received: from mongo by mongo.pixar.com with smtp
(Smail3.1.28.1 #15) id m0qD0jo-0007rca; Sun, 12 Jun 94 18:22 PDT
Date: Sun, 12 Jun 94 18:22 PDT
Message-Id: <9406130122.AA26258@thokk.cs.cornell.edu>
Errors-To: bruce@pixar.com
Reply-To: mdw@cs.cornell.edu
Originator: debian-devel@pixar.com
Sender: debian-devel@pixar.com
Precedence: bulk
Priority: non-urgent
From: mdw@cs.cornell.edu (Matt Welsh)
To: debian-devel@pixar.com
Subject: New dpkg spec
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
Status: RO
Here is a new version of the dpkg spec incorporating the gist of
Steven White's proposal for configuration file updating.
If you have any comments please let me know ASAP, as I'm about
to implement the mechanism described herein. I'd especially
like to hear (directly) from anyone opposed to the mechanism,
with reasonable arguments as to why it's a bad idea.
--
Debian GNU/Linux Binary Package and Installation Tools specification
Matt Welsh, < mdw@sunsite.unc.edu>
v0.4, 12 June 1994
-1. Changes in this version
The method used to update configuration files has been revamped.
Sections 1.2.2 and 2.2 contain the relevant changes.
0. Introduction
This specification describes the format of `.deb' binary packages
for the Debian GNU/Linux distribution. It also describes the various
installation tools that manipulate packages; this includes `dpkg' and
the dpkg front-end.
All Debian package maintainers should follow the binary package
specification contained herein; given the description of dpkg and
related tools, you will know how binary packages will be installed,
upgraded, and configured. These subjects are intimately tied together,
which is why there is one specification for all of them.
Please see the Debian Source Package Guidelines for information concerning
the creation of Debian Source Packages (from which Binary Packages are
built).
Note: This is a PRELIMINARY specification. It has not been implemented yet.
Therefore, members of the Debian development group should make comments,
suggestions, and outright corrections to it before we begin to implement
dpkg and the install tools as described here. Critique should be mailed
to myself (mdw@sunsite.unc.edu) and Ian Murdock (imurdock@gnu.ai.mit.edu).
1. Binary Package Format
A Debian Binary Package (hereafter refered to as a `package') consists
of two parts: A set of files which make up the software package in
question, and configuration/installation information. This configuration
information will consist of package-specific installation and configuration
scripts; information on the origin, version, and maintainer of the package;
information on package dependencies and conflicts, and so forth.
Much of the rationale for the following package format specification is
based on the installation tools, which are described in the next section.
If the reasoning behind a particular aspect of this format is not clear,
section 2, below, should clear up any confusion.
Debian packages will be stored as a single gzipped tar file. Canonically,
package filenames will end in the extension `.deb', although the installation
tools will not depend at all on the package filenames.
1.1 Package contents
The package tar file should contain all files included in the software
package, archived from the root directory (`/'). The installation tools
will extract packages from the root directory of the system, so everything
should be in the right place within the package tar file. In addition, all
file permissions and ownership information of files in the package should
be correct as they are archived. `tar' will be used to extract package
files, which will set the permissions and ownership of the files as they
are extracted.
The following guidelines should be followed for file layout and permissions
within the binary package:
* The location of installed files must follow the Linux Filesystem
Standard. The latest version of this document can be found
alongside this Debian source package guidelines. Specific
questions about following the filesystem standard can be
addressed to Daniel Quinlan .
* All directories should be mode 755, with the exception of
special "system" directories that need to be another mode. The
ownership of the directory should be consistent with its mode;
if a directory is mode 775, then it should be owned by the group
that needs write access to it. Use common sense in assigning
permissions and ownerships to directories, and make sure that
what is done is secure if it is not the standard configuration.
* In general, normal binaries should be mode 755 and owned by
root.bin. If there is a good reason to use a different mode
or ownership, then feel free to do so, but do try to be as
consistent as possible with the rest of the system.
* Setuid/setgid binaries should be mode 4711/2711 and owned by
the appropriate user/group. For security reasons, please do
not make setuid/setgid binaries mode 4755/2755.
* Library files should generally be installed as mode 644 and
owner root.root; however, if the package requires different
permissions or ownerships to function correctly, then they
should obviously be used instead.
* Manual pages should be mode 644 and owned by root.root. The
nroff source must be installed. Do not install a pre-formatted
catman page.
* Man pages should be edited to reflect the Debian package. For
example, references of /etc/utmp should be changed to
/var/adm/utmp. Documentation really should be consistent with
the system.
* Info documents should be mode 644 and `gzipped' when installed.
* Any other documentation that comes with the package should be
installed at the discretion of the package maintainer. Text
documentation should be mode 644, `gzipped' and installed to
/usr/doc. If a subdirectory of /usr/doc is warranted, then
please feel free to create one.
* Any example files (for example, sample configuration files)
should be placed in /usr/doc/examples. If the file is normally
a "hidden" file, such as `.emacs', then please call it
`dot.emacs' to avoid confusion.
* All symbolic links should be relative, not absolute. Absolute
links, in general, cause problems when a filesystem is not
mounted where it ``normally'' resides (for example, when mounted
via NFS). In certain cases, however, relative links may also
cause similar problems (for example, if /usr is mounted on
/foo/bar, and /foo/bar/spool is a link to ../spool it will not
find it); in this case, feel free to use absolute links, but they
should be used only when necessary. I have generally made links
into /etc and /var absolute and all other links relative. There
may be other cases in which absolute links are necessary.
1.2 Configuration information
In addition to the contents of the software package, packages will also
contain configuration information, stored in the directory `/.DEBIAN'
at the root of the tar file. Files within the .DEBIAN/ directory are:
.DEBIAN/control Master package configuration file
.DEBIAN/conffiles List of package configuration files
.DEBIAN/preinst Package pre-installation script
.DEBIAN/postinst Package post-installation script
.DEBIAN/prerm Package pre-removal script
.DEBIAN/postrm Package post-removal script
Of these, only .DEBIAN/control is required. The various installation
scripts, and the configuration files list, will only be used if they
are present.
1.2.1 Control file format
The .DEBIAN/control file contains a number of fields. Each field begins
with a tag, such as `PACKAGE' or `VERSION' (case insensitive), followed
by a colon, and the body of the field. Fields are delimited only by
field tags. In other words, field text may be multiple lines in length,
but the installation tools will generally join lines when processing
the body of the field.
The required fields in the control file are the following:
PACKAGE: < Short name of package>
VERSION: < Version number>
MAINTAINER: < Name and e-mail address of package maintainer>
DESCRIPTION: < Description of package>
There is but one restriction on the format of control file fields:
The value of `PACKAGE' will be used to generate filenames by the
installation tools, and therefore should be a valid filename prefix
(i.e., no embedded slashes), and not contain any whitespace.
The optional fields in the control file are the following:
DEPENDS: < Short names of prerequisite packages>
RECOMMENDED: < Short names of related, recommended packages>
OPTIONAL: < Short names of related, optional packages>
CONFLICTS: < Short names of packages which conflict with this one>
An example of a .DEBIAN/control file would be:
PACKAGE: emacs
VERSION: 19.22
MAINTAINER: Daniel Quinlan < quinlan@bucknell.edu>
DESCRIPTION: The extensible, customizable, self-documenting,
real-time display editor
DEPENDS: emcsmisc, emcselc1, emcselc2
RECOMMENDED: emcselz1, emcselz2, emcsinfo
OPTIONAL: emcsetc
CONFLICTS: emacs_nox
In this case, the `emacs' package will contain the binary with X support,
and `emacs_nox' contains the binary without X support. The control
file for `emacs_nox' would contain a `CONFLICTS: emacs' line accordingly.
1.2.2 Configuration file list format
The contents of .DEBIAN/conffiles is simply a list of files in the
package which should be updated by a ``foolproof'' upgrade mechanism when
the package is installed. This mechanism will ensure that package-specific
configuration files are not overwritten when a package is upgraded, unless
the user wishes the installation tools to do so.
Typically, files listed in .DEBIAN/conffiles are package-specific
configuration files, which (according to the Linux Filesystem Standard)
are stored in /etc. For example, the `sendmail' package may contain the
file `/etc/sendmail.cf', which we do not wish to overwrite automatically
when the user upgrades the sendmail package. Only those files listed in
DEBIAN/conffiles will be updated intelligently when a package is upgraded;
all other files in the package will be overwritten by the upgrade process.
The exact method for .DEBIAN/conffiles file update is covered in Section 2,
below.
1.2.3 Installation script format
The files `preinst', `postinst', `prerm', and `postrm' are optional
(bash or perl) scripts contained within the .DEBIAN directory
in the package. As the names imply, if these scripts exist they will
be executed before installing the package, after installation, before
package removal, and after removal, respectively.
These scripts can be used to perform any site-specific package configuration.
Because the scripts will be exectued by the dpkg front-end, it is guaranteed
that the scripts will be executed interactively. User input from the
scripts should be read from standard input, not the user's terminal.
Similarly, output should be sent to standard output.
Note that `postinst' will be executed AFTER the files listed in
DEBIAN/conffiles have been updated. In this way the script can
do site-specific configuration for the package based on the actual
configuration files selected by the user; there is no guesswork
involved.
1.3 Creating a Debian Binary Package
Packages are merely gzipped tar files with the embedded .DEBIAN directory.
Therefore, the canonical way to create a binary package is to follow
these steps:
1) Install the entire package in a clean directory tree on the
source system, (for example, /usr/src/root_dir), ensuring that
file permissions and ownerships are correct;
2) Create the `.DEBIAN' directory at the root of this tree;
3) Within `.DEBIAN', create the files `control', as well as
(optionally) `conffiles', `preinst', `postinst', `prerm',
and `postrm';
4) Issue a command such as:
cd /usr/src/root_dir; tar cf - . | gzip -9c > ../foo.deb
To create the package `foo.deb' from the contents of the
directory `root_dir'.
2. Package Installation Tools
The Debian package installation tools will consist of two applications:
`dpkg', which is responsible for package installation, removal, and
sanity-checking; and a dpkg front-end, which is responsible for
locating and selecting packages to install, as well as package configuration.
Note that dpkg does nothing about package configuration; it is only
responsible for installing the package software on the system. The
front-end (which can be given a number of interfaces) will select packages,
invoke dpkg for each, and handle all package configuration issues.
One of the reasons for this is that the front-end should handle all
interactive use of the installation tools. In addition, the user may wish
to install many software packages at one time, but delay configuration
until the installation process has been completed. Making dpkg and the
front-end independent of one another is the best way to achieve this.
Note that dpkg will rarely be used alone; nearly all packages will
require some kind of configuration. For those who wish to do things
`by hand', one of the available front-ends for dpkg will be a script
that invokes dpkg to install a named package, and immediately configure
it. Of course, a number of smarter, more interface-laden front-ends
will be available as well, both for terminal and X-based environments.
2.1 dpkg
The format of the dpkg command is as follows:
dpkg [ -i | --install ] < package>
dpkg [ -r | --remove ] < package>
dpkg [ -l | --list ]
dpkg [ -c | --contents ] [ -d | --describe ] [ -v | --version]
< package>
dpkg [ -s | --search ] < regexp>
dpkg [ -s | --extract ] < package> [ < directory> ]
Where < package> is the pathname of a Debian package file, and
< regexp> is a regular expression.
Invoking dpkg with the `-i' option will install the named < package> on
the system. Essentially this consists of:
1) Determining if another version of this package is already
installed, and if so, remove it;
2) Unpacking the contents of the package from the system root
directory;
3) Moving the contents of the /.DEBIAN directory (created by
unpacking the tar file) to the appropriate location (see
below).
4) Generate a list of files installed from the package (see below).
Note that the directory /.DEBIAN will be created by the installation
procedure, and subsequently moved to another location. Therefore,
dpkg will exit with an error message if .DEBIAN already exists (which
means that another dpkg process is running on this system, or a
previous dpkg crashed before making it to step (3)).
dpkg will move the contents of /.DEBIAN to /var/adm/dpkg as follows:
* /.DEBIAN/control will be moved to /var/adm/dpkg/< package>.control,
where < package> is the name of the package given in the control
file (not determined from the package filename).
* The installation scripts, /.DEBIAN/{pre,post}{inst,rm}, will be
moved to /var/adm/dpkg/< package>.{pre,post}{inst,rm}.
* The configuration files list, /.DEBIAN/conffiles, will be
moved to /var/adm/dpkg/< package>.conffiles.
During the installation procedure, dpkg will generate a list of files
in the package, and store it in the file /var/adm/dpkg/< package>.list.
Invoking dpkg with the `-r' option will remove the named package, if it
has been installed on the system. Essentially this consists of deleting
all files on the system from the corresponding filelist in
/var/adm/dpkg/< package>.list. This will also delete all information
about the package in /var/adm/dpkg.
Invoking dpkg with the `-l' option will list all packages installed on
the system. It will print a short, one-line summary of each package, such as:
Name Version Install date
--------------- --------------- -------------
groff 1.0.9 13 May 1994
emacs 18.59 23 Aug 1993
Installation dates can be gathered from the ctime of the corresponding
files in /var/adm/dpkg, or amended to the control file at installation
time.
The `-c', `-v', and `-d' options give information about packages
which match the given regular expression. The named packages may be
either installed, in which case < package> specifies an installed
package name, or uninstalled, in which case < package> is a pathname
to a (not yet installed) package.
`-c' prints the contents of the package, in ls -adl format. `-v' prints
version and maintainer information for the package. `-d' prints the
description of the package from the control file.
The `-s' option searches for the named file(s) (given by the regular
expression < regexp>) in all installed packages, and prints the names
of the package(s) in which it is found. For example, `dpkg -s "?dit*"'
might print:
groff
xditview
The regular expression is matched against the installed-package filelists
in /var/adm/dpkg/*.list.
The `-e' option will extract the package control directory .DEBIAN from
the named < package>, and place it in the named < directory> (or
`./.DEBIAN' if no < directory> is specified). For example,m
dpkg -e foo.deb /tmp/foo-information
will copy `/.DEBIAN/*' from the package to `/tmp/foo-information'.
The directory `.DEBIAN' will _not_ be created beneath the named
< directory>.
2.2 dpkg Front-end
There will be several front-ends to dpkg available; they will provide
a friendly user interface for finding and selecting packages to
install/remove, as well as take care of package configuration.
For example, when the user wishes to install a set of packages at
one time, dpkg will be invoked for each package, but the package-specific
installation scripts (.DEBIAN/preinst et. al.) will be executed in
one batch for all packages.
When installing packages, the front-end will handle package configuration
in the following way:
1) Before the package has been installed (using dpkg), the
contents of the /.DEBIAN directory will be extracted from
the package, and saved in a temporary directory.
2) If /.DEBIAN/preinst exists, it will be executed;
3) For all files listed in /.DEBIAN/conffiles,
3a) If < file>.dpkg-old exists, delete it.
3b) If < file>.dpkg-new exists, delete it.
3c) If < file>.dpkg-tmp does not exist,
copy < file> to < file>.dpkg-tmp.
4) dpkg will be invoked to install the package;
5) For all files listed in /.DEBIAN/confffiles,
5a) If < file>.dpkg-tmp and < file> are identical,
delete < file>.dpkg-tmp.
5b) Otherwise, give the user the following options:
1. "Use new configuration file."
< file>.dpkg-tmp is renamed to < file>.dpkg-old.
Give user option to delete < file>.dpkg-old.
2. "Use old configuration file."
< file> is renamed to < file>.dpkg-new.
Give user option to delete < file>.dpkg-new.
< file>.dpkg-tmp is renamed to < file>.
The front-end will be able to select user defaults for
these actions.
6) If /.DEBIAN/postinst exists, it will be executed;
7) Remove the front-end's temporary copy of /.DEBIAN files.
The front end will handle package removal in the following way:
1) Execute /var/adm/dpkg/< package>.prerm, if it exists;
2) For all files in /var/adm/dpkg/< package>.conffiles,
2a) If < file>.dpkg-new exists, delete it.
2b) If < file>.dpkg-old exists, delete it.
3) Save a copy of /var/adm/dpkg/< package>.postrm, if it
exists (as dpkg will delete all files from /var/adm/dpkg
corresponding to this package);
4) Invoke dpkg to remove the package (as well as
/var/adm/dpkg/< package>* files) from the system;
5) Execute saved copy of /var/adm/dpkg/< package>.postrm, if
it exists.
3. Comments
Please send your comments on this specification to M. Welsh
(mdw@sunsite.unc.edu) and Ian Murdock (imurdock@gnu.ai.mit.edu).
This specification is necessarily vague, because many of the details
of implementation have not been determined yet. However, most of
the major issues should be presented here, and I welcome your
suggestions and ideas.
Once this specification is complete we will be able to produce these
tools, and give package maintainers something solid to go by. I'd like
for this to be as long-term as possible, so that maintainers don't
have to modify their package distribution as the spec changes. Therefore,
if you can think of potential future extensions of this specification,
now is the time to bring them up.