Policy Weekly Issue #5
DEBIAN POLICY WEEKLY, #5 (January 13, 1998)
The following message is a list of topics related to the Debian Policy which
are currently under discussion or which will be discussed in the near
future. This summary is sent to the debian-policy mailing list periodically
by the Debian Policy Manager.
A copy of this mail is sent to debian-devel to keep other developers
up-to-date. Please send any replies to the debian-policy mailing list.
Please do not quote the whole mail if you are only referring to a single
section to save bandwidth.
----------------------------------------------------------------------------
The Policy Manual on the Web
This message can also be read online at
http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-policy/weekly/
The Home Page of the Debian Policy Manual can be visited at
http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-policy/
This page contains links to the current documents, information about the
current development version (2.3.1.0 DRAFT), and links to related documents.
----------------------------------------------------------------------------
Policy changes that need to be approved
The following policy changes have been developed during recent discussion on
the mailing lists. If there are no objections, these changes will become
`official' soon.
1. Bash vs Bourne shell
2. Maintainer's reaction on non-maintainer uploads
3. How packages can register cron jobs
4. Gzipped symlinks
5. Standardized handling of /etc/init.d script options
6. Consistent handling of the Backspace and Delete keys
7. Linking shared libraries with -lc
8. How to do mass-bug-reports correctly
9. Non-interactive build process of packages
10. System-wide environment variables used for program
configuration
11. Policy on stripping static libraries
12. New upload procedure
13. New virtual packages
14. Games using X11
15. Package versions based on dates
Policy topics about which I need additional input
The following topics have been discussed on the mailing lists or in private
mail. I need more information and personal opinions about these topics to
prepare a policy change:
[none]
Policy topics which need to be discussed
The following ideas have been mentioned in recent discussions. Any input is
appreciated.
16. Use of /usr/src
Postponed policy discussions
The following topics showed up in the past and have been postponed. They
will be covered in one of the next Policy Weekly postings.
17. Filesystem location of non-english documentation files
18. X Window Manager policy
19. How daemons should be handled in postinst scripts
20. Manual page inconsistencies
21. Documentation policy
22. Proposed source package format
23. FHS migration
24. PGP signed packages and the `Origin' field
25. Bashism in debian/rules
26. Device locking
27. When to increment a package version number
28. Policy for icons
----------------------------------------------------------------------------
Topic 1: Bash vs Bourne shell
STATE: APPROVAL
There has been a long discussion on debian-policy about which shell features
can be assumed to be provided by /bin/sh. Currently, a lot of packages use
bash-specific features but specify "#!/bin/sh" as interpreter. Installing
another shell (e.g., ash) as /bin/sh will break these scripts.
Since the use of other shells than bash makes sense for some systems (e.g.,
the "ash" shell requires much less disk and RAM space than "bash"), we
define which functionality packages can expect from /bin/sh. If a certain
shell script requires more functionality than that, the script has to
specify the corresponding shell program (e.g., "#!/bin/bash") and has to
depend on the corresponding package (unless that is tagged `Essential', as
in the case of bash).
I present the following policy change for approval. If noone objects, this
will become official policy:
The standard shell interpreter `/bin/sh' may be a symbolic link to
any POSIX compatible shell. Thus, shell scripts specifying
`/bin/sh' as interpreter may only use POSIX features. If a script
requires non-POSIX features from the shell interpreter, the
appropriate shell has to be specified in the first line of the
script (i.e. `#!/bin/bash') and the package has to depend on the
package providing the shell (unless the shell package is marked
`Essential', of course).
Restrict your script to POSIX features when possible so that it
may use /bin/sh as its interpreter. If your script works with ash,
it's probably POSIX compliant, but if you are in doubt, use
/bin/bash.
----------------------------------------------------------------------------
Topic 2: Maintainer's reaction on non-maintainer uploads
STATE: APPROVAL
The policy on doing non-maintainer releases is currently not very detailed.
As doing non-maintainer releases is getting quite common I suggest to
specify more details in the policy.
The following proposal is assembled from several previous discussions.
Unless someone objects, I'll include the following changes in the
Developer's Reference:
* (As current policy says) the person doing the non-maintainer upload
should send a bug report to the bug tracking system explaining his/her
changes. This is extremly important so that the usual maintainer gets
notified about the interim release.
* The normal maintainer should do at least one of
o apply the diff
o read the diff and decide on each part of it themselves
o read the description of the patches and ensure that they fix each
problem that was fixed in the non-maintainer release.
* If the non-maintainer upload fixes some bugs, the bugs should not be
closed. However, the person making the non-maintainer release should
send a short message to the bug tracking system to all the fixed bugs
explaining that they have been fixed. This way, the maintainer and
other people will get notified about that.
----------------------------------------------------------------------------
Topic 3: How packages can register cron jobs
STATE: APPROVAL
The current policy does not allow packages to touch /etc/crontab anymore.
This is because we don't allow packages to modify other packages
configuration files.
Thus, currently packages can either place a file into one of the
/etc/cron.{daily,weekly,monthly} directories or ask the cron maintainer to
include an entry for their package in the cron package.
Since a few packages have to register cron jobs which need to be run more
often than `daily', the cron package has been changed to read all files in
/etc/cron.d too and interpret these as additions to /etc/crontab. With that,
every package can include a conffile /etc/cron.d/<pkg> which contains the
necessary cron jobs.
Unless someone objects, I'll update the policy manual to describe this.
----------------------------------------------------------------------------
Topic 4: Gzipped symlinks
STATE: APPROVAL
Current policy requires all manual pages to be installed compressed. In some
cases where a program has different names, the manual page file might be a
symbolic link pointing to another file, for example "nview.1.gz ->
nvi.1.gz".
However, in some cases the maintainers installed the links without trailing
".gz", but pointing to a gzipped file, as in "nview.1 -> nvi.1.gz". Though
this works perfectly with "man", it's completely controversal to logic (at
least for me :). However, I've been requested to clarify this in the policy
manual.
So unless someone objects, I'll add the following statement to the section
about symbolic links:
A symbolic link pointing to a compressed file should always use
the same file extension as the referenced file. (For example, if a
file called "foo.gz" is referenced by a symbolic link, the link
filename has to end with ".gz" too, as in "bar.gz".)
----------------------------------------------------------------------------
Topic 5: Standardized handling of /etc/init.d script options
STATE: APPROVAL
In Nov/Dec 97 there was a discussion on debian-policy about which standard
behaviour of /etc/init.d scripts can be expected. The result of the
discussion is the following policy proposal. Unless there are any
objections, this will become official policy.
Each /etc/init.d script _has_ to provide the following options:
start starts the daemon(s)
stop stops the daemon(s)
restart has to stop and start the daemon(s)
(just making the daemons reload their configuration
files is _NOT_ enough)
reload if possible, make daemon(s) refresh their configuration files
(it is important, that the daemon(s) are not stopped
by this option)
force-reload if possible do a "reload", otherwise "restart"
All these options have to be provided by all scripts. If an option is
not possible (i.e., the daemon does not support reloading) or fails,
an appropriate error message has to be written to stderr and a
non-zero error level has to be returned.
----------------------------------------------------------------------------
Topic 6: Consistent handling of the Backspace and Delete keys
STATE: APPROVAL
The following proposal has been assembled by Ian Jackson and presented to
debian-policy twice now. It can be considered as first step towards the
`Consistent Keyboard Configuration' goal.
There has been some discussion about the proposal already. Unless someone
detects some major problems with it, we should not raise the discussion
again. So, if noone objects, this will become policy.
What we want is:
* `<--' always deletes the character to the left of the cursor.
* `Delete' always deletes to the right.
* `Control'+`H' produces help in Emacs, as before.
We want this to be true for the console, for X, and even if you use
rlogin or telnet to get from one system to another.
What we should do is the following:
* `<--' generates KB_Backspace in X.
* `Delete' generates KB_Delete in X.
* X translations are set up to make KB_Backspace generate ASCII DEL,
and to make KB_Delete generate ESC [ 3 ~ (this is the vt220 escape
code for the `delete character' key). This must be done by loading
the resources using xrdb on all local X displays, not using the
application defaults, so that the translation resources used
correspond to the xmodmap settings.
* The Linux console is configured to make `<--' generate DEL, and
`Delete' generate ESC [ 3 ~ (this is the case at the moment).
* X applications are configured so that Backspace deletes left, and
Delete deletes right. Motif applications already work like this.
* stty erase ^? .
* The `xterm' terminfo entry should have ESC [ 3 ~ for kdch1, just
like TERM=linux and TERM=vt220.
* Emacs is programmed to map KB_Backspace or the `stty erase'
character to delete-backward-char, and KB_Delete or kdch1 to
delete-forward-char, and ^H to help as always.
* Other applications use the `stty erase' character and kdch1 for the
two delete keys, with ASCII DEL being `delete previous character'
and kdch1 being `delete character under cursor'.
This will solve the problem except for:
* Some terminals have a <-- key that cannot be made to produce
anything except ^H. On these terminals Emacs help will be
unavailable on ^H (assuming that the `stty erase' character takes
precedence in Emacs, and has been set correctly). M-x help or F1
(if available) can be used instead.
* Some operating systems use ^H for stty erase. However, modern
telnet versions and all rlogin versions propagate stty settings,
and almost all UNIX versions honour stty erase. Where the stty
settings are not propagated correctly things can be made to work by
using stty manually.
* Some systems (including previous Debian versions) use xmodmap to
arrange for both <-- and Delete to generate KB_Delete). We can
change the behaviour of their X clients via the same X resources
that we use to do it for our own, or have our clients be configured
via their resources when things are the other way around. On
displays configured like this Delete will not work, but <-- will.
* Some operating systems have different kdch1 settings in their
terminfo for xterm and others. On these systems the Delete key
will not work correctly when you log in from a system conforming to
our policy, but <-- will.
----------------------------------------------------------------------------
Topic 7: Linking shared libraries with -lc
STATE: APPROVAL
One of the release goals for Debian 2.0 has been to link all shared
libraries dynamically against each other. This can be done by using the
`-lc' option when linking the library. With that, the library will contain
valuable dependency information about which other libraries the library is
linked against.
Unless someone objects, I'll change the policy manual to force this linker
option for all shared libraries.
----------------------------------------------------------------------------
Topic 8: How to do mass-bug-reports correctly
STATE: APPROVAL
More and more people are doing mass-bug-reports (that is, reporting a lot of
bugs on the same topic against different packages) lately. Usually, this is
a very good thing since it helps improving the quality of our distribution.
However, in some cases people started to file bug reports on topics which
have not been included in the policy manual or which were only covered
partially, resulting into large discussions.
To prevent this situation to happen again, I suggest to document the
following in the Developer's Reference. Unless someone objects, I'll do
this.
If you report more then 10 bugs on the same topic at once, it is
highly suggested that you send a short message to debian-devel
describing your intention before sending the reports. This will
allow the other developers to verify if the bug report is correct.
In addition, it will prevent the situation where several
maintainers start filing the same bug reports without knowing of
each other...
Note, that when sending lots of bugs on the same subject, you
should consider sending the bug reports to the `maintonly' address
(instead of `submit') so that the bug reports are not forwarded to
the bug distribution mailing list.
(If someone knows a better formulation for this, please tell me.)
----------------------------------------------------------------------------
Topic 9: Non-interactive build process of packages
STATE: APPROVAL
Some packages require user-interaction during the build process, i.e., when
running a `dpkg-buildpackage' on the source. This makes it hard for someone
other than the usual maintainer to compile the package (for example, for
maintainers porting the package to other architectures) and makes
auto-compiling the package impossible.
The Packaging Manual already contains the following statement:
3.2.1 debian/rules - the main building script
[...]
The targets which are required to be present are:
build
This should perform all non-interactive configuration and compilation of the
package. If a package has an interactive pre-build configuration routine, the
Debianised source package should be built after this has taken place, so that
it can be built without rerunning the configuration.
[...]
Current (unwritten) policy is to require that all other targets of
debian/rules are also non-interactive.
Unless someone objects, the text in the Packaging Manual will be fixed to
document this.
----------------------------------------------------------------------------
Topic 10: System-wide environment variables used for program configuration
STATE: APPROVAL
It has been unwritten policy for a long time now, that no package may use
system-wide environment variables for configuration of its programs. (The
reason for this is that not all shells parse /etc/profile.)
To document this policy, I'll add the following text to the Policy Manual,
unless someone objects.
No program may depend on environment variables to get reasonable
defaults. (That's because these environment variables would have
to be set in a system-wide configuration file like /etc/profile,
which is not supported by all shells.)
If a program should depend on environment variables for its
configuration, the program has to be changed to fall back to a
reasonable default configuration if these environment variables
are not present.
Furthermore, as /etc/profile is a configuration file of the bash
package, no other package may include any environment variables or
other commands in that file.
----------------------------------------------------------------------------
Topic 11: Policy on stripping static libraries
STATE: APPROVAL
In December, we had a discussion on debian-devel about how we should treat
static libraries WRT stripping. Currently, the policy only specifies how
shared libraries should be stripped, but nothing is said about stripping
static libraries.
The following stripping policy has been suggested in the discussion. Unless
someone objects, I'll change the policy text to use this scheme:
runtime pkg: shared lib stripped with --strip-unneeded
develop pkg: static lib stripped with --strip-debug
debug pkg: static lib unstripped
----------------------------------------------------------------------------
Topic 12: New upload procedure
STATE: APPROVAL
We've developed a new upload procedure on debian-policy and debian-devel
some time ago (in Nov 97, I think). The major change is that bug reports are
closed by a script on master after the upload has been processed.
Here is a list of the major changes since my last posting on this topic:
* Changed `closes' and `closed' term into `fixes'
(This has been suggested by a few people. Please tell me if `closes'
would still be preferred.)
* Relaxed syntax of pattern which detects `fixes' lines: spaces are
allowed in some places, pattern is case-insensitive, "bug" can be
omitted
(I don't think there is a risk that maintainers will accidentially
close bugs. If this should happen, the bug can always be reopened
again. There is one other problem, though: Since spaces are allowed, it
could happen that the editor "wraps" long lines into two. This will
_not_ be handled by the script, which means that some fixed bugs will
stay open. Again, actually no big problem.)
So, here is the current proposal. If noone objects I'll report this as a
`wish-list' bug report against ftp.debian.org and dpkg to get it
implemented.
Any comments are welcome! (But please consider that this topic has been
discussed in detail already.)
(Note, that `dinstall' is the script on master which processes all new
uploads and installs them in the Debian ftp directory.)
Procedure for package uploads
-----------------------------
Maintainer's part:
1.) [Only for new packages:] discuss the package on debian-devel
2.) Upload package to master, chiark, erlangen, whatever
dinstall's part:
3.) [check for new packages every ten minutes]
Check if package upload was complete and the files are correct
(i.e. check PGP signature, MD5 sums, correct .changes file, etc.)
If there is an error send mail to the maintainer and stop
4.) Send announcement to debian-devel-changes in case of an "unstable"
or "experimental" upload
5.) [once a day]
Install packages into the archive
(In case of a new package or a stable upload, this requires the
acknowledgement of the archive maintainer)
6.) Send announcement to debian-changes in case of a "stable" upload
7.) [For source uploads only]
Close bug reports that are fixed with this package upload
(see below for details).
Details about how bug reports are closed
----------------------------------------
With the new upload procedure, bugs will usually be closed by the
dinstall script, not be the maintainer. This has the advantage that
the maintainer has less work to do and that the bug reports get closed
only after the package has been installed in the ftp
server. (Currently, most maintainers close the bugs after having the
package uploaded. Sometimes, it takes a long time until the package
gets actually installed and some users which still use the old version
might file the bug report again...)
So, if a package upload fixes some bugs, the maintainer should include
some tags in the debian/changelog file that use the following syntax
(Perl regexp syntax, case-insensitive):
/fixes:\s*(bug)?\#\d+\(,\s*(bug)?\#\d+\)*/i
Here is an example for those that do not speak Perl:
foo (1.0-5) unstable; urgency=low
* Recompiled with libc6, fixes: Bug#98765, Bug#98766
* Removed `rm -rf /' from postrm script, fixes:#99999
-- Wile E. Coyote <coyote@debian.org> Wed, 29 Oct 1997 14:22:37 -0600
The new updated parsechangelog/debian script will check for these
markers and insert a new "Fixes:" field into the .changes file:
Format: 1.5
Date: Wed, 29 Oct 1997 14:22:37 -0600
Source: foo
Binary: foo
Architecture: source all
Version: 1.0-5
Distribution: unstable
Urgency: low
Maintainer: Wile E. Coyote <coyote@debian.org>
Fixes: 98765 98766 99999
Description:
foo - Foos and Bars
Changes:
foo (1.0-1) unstable; urgency=low
.
* Recompiled with libc6, fixes: Bug#98765, Bug#98766
* Removed `rm -rf /' from postrm script, fixes:bug#99999
Files:
66909c6d1adc62c961f0618bb58fd2b5 194 doc extra foo_1.0-5.dsc
c4b3cabd889396dcf5251e0ea529bea7 983 doc extra foo_1.0-5.tar.gz
6d653b5f4dffd6e45109380e86dfe4e6 1038 doc extra foo_1.0-5_all.deb
When dinstall discovers a source upload which contains the `fixes:'
field it closes the listed bug reports by sending messages of the
following form to the bug tracking system:
(Note, that the message header is quite important. It must appear to
come from the developer submitting the package, so that the bug system
sends its notifications &c to the right place, and it must make sense
to the user.)
From: <maintainer from changes file>
To: <nnn>-submitter@bugs
Bcc: <maintainer from changes file>, <nnn>-close@bugs
Subject: Bug#<nnn>: fixed in <package> <version>
We believe that the bug you reported is fixed in the latest version
of <package> (<version>), which has been installed in the
Debian FTP archive as:
<path/to/binary/package>
<path/to/source/package>
#if NOT_INSTALLED_INTO_STABLE
NB that this package is not part of the released stable Debian
distribution; it may have dependencies on other unreleased software,
or other instabilities. Please take care if you wish to install it.
The bugfix will eventually make its way into the next released
Debian distribution.
#endif
A summary of the changes between this version and the previous one
is attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <nnn>@bugs, and the
maintainer will if appropriate reopen the bug report while your
concerns are addressed.
Debian distribution maintenance software
pp.
<maintainer from changes file> (supplier of updated <package>)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <contact address>.)
<.changes entry>
----end-of-email----
Additional notes
----------------
1. With the current proposal, bug reports are only closed for source
uploads. (That's important since we don't want our bugs being closed
several times, once for each architecture :-)
However, some bug reports may be architecture specific. In these cases,
the bug reports have to be closed by the maintainer "by hand".
2. Before sending the announcement of the package upload, dinstall
will check the maintainer's home directory on master if it contains a
`~/.changes-template' file, in which case the file contents will be
included at the top of the announcement message.
The file could look like this:
-----cut-here-----
Hi folks!
as usual you'll find this package also in ftp://ftp.my.site/my/dir/
-----cut-here-----
----------------------------------------------------------------------------
Topic 13: New virtual packages
STATE: APPROVAL
The following virtual packages have been requested: `pascal-compiler' and
`libc-dev'.
Some packages like noweb need to depend/suggest a pascal-compiler and we
have at least two pascal compilers now: gpc, and p2c. With that, I think it
would be good to have this virtual package. (Note, that we already have
virtual packages for `c-compiler' and `fortran77-compiler'.)
The `libc-dev' package has already been used for a while for packages, which
depend on the development package of a libc.
Unless someone objects, these virtual packages will be added to the
authoritative list.
----------------------------------------------------------------------------
Topic 14: Games using X11
STATE: APPROVAL
FSSTND (and FHS too) specifies that `games' should be installed into
/usr/games instead of /usr/bin. However, the standard does not specify
whether games for X11 should go into /usr/games or /usr/X11R6/bin.
Our interpretation of FSSTND is to put games using X11 into /usr/games, just
as non-X11 games.
Unless someone objects, I'll document this in the policy manual.
----------------------------------------------------------------------------
Topic 15: Package versions based on dates
STATE: APPROVAL
Some time ago, there was a discussion on debian-policy about how version
numbers should be formatted if there are based on dates. The following
policy proposal is a compromise between the different ideas that have been
presented in the discussion.
If everyone agrees with this text, I suggest that it's added to the
Packaging Manual.
In general, Debian packages should use the same version numbers as
the upstream sources.
However, in some cases where the upstream version number is based
on a date (i.e., a development `snapshot' release) dpkg cannot
handle these version numbers currently, without epochs. For
example, dpkg will consider `96May01' to be greater than
`96Dec24'.
To prevent having to use epochs for every new upstream version,
the version number should be changed to the following format in
such cases: `96-05-01', `96-12-24', and starting with the year
2000 `2000-12-24'.
Note, that other version formats based on dates which are parsed
correctly by dpkg should _NOT_ be changed.
----------------------------------------------------------------------------
Topic 16: Use of /usr/src
STATE: DISCUSSION
There was a discussion on the use of /usr/src on debian-devel a few days
ago. A few people wanted /usr/src to be available for the local system
administrator only, which means that no package may touch /usr/src (same as
/usr/local).
However, both FSSTND and FHS are very clearly state:
/usr/src :
[...]
Any non-local source code should be placed in this subdirectory.
IMHO, /usr/local/src is the place for the sysadmin, /usr/src is the place
for packages.
Unless convincing arguments are presented, this will not be changed.
Comments are appreciated.
----------------------------------------------------------------------------
-- Christian Schwarz
schwarz@monet.m.isar.de, schwarz@schwarz-online.com,
Debian has a logo! schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
Check out the logo PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA
pages at http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-logo/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: