Status of Debian Policy
Note, that this is the first message of this type. My apologizes if
the mail is too large. I was thinking about creating an extra mailing
list of policy related discussions, or about setting up a HyperNews
server to discuss these topics. However, I think this is (better:
should) be important for all Debian developers. I'm not sure if
splitting this mail into 12 mails (a summary and one for each topic)
would make replying easier. Please give me feedback about this.
PLEASE EVERYBODY: DO NOT QUOTE THE WHOLE MAIL IF YOU ARE ONLY REPLYING
TO A SINGLE TOPIC!
---------------------------------------------------------------------------
The following message is a list of items to be completed for the next
version of the Debian Policy Manual. It is posted on debian-devel
periodically by the Debian Policy Manager, Christian Schwarz, to get
more feedback about certain policy issues that came up in the past
several times but without a resolution or decision.
This document was last modified at Time-stamp: <97/06/15 17:04:50 schwarz>
***************************************************************************
The "Official Policy Manual Home Page" can be visited at
http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-policy/
This page contains links to the current version of the Policy Manual
(2.1.3.3), the current development version (2.2.0.0 DRAFT), and
links to related documents.
***************************************************************************
Overview
========
The following topics have been changed in the current development
version of the Policy Manual (2.2.0.0 DRAFT). I need feedback from
several developers. If there are no objections, these changes will be
included in the next version of the Policy Manual (status:
NEED-APPROVAL):
1. policy for user and group ids (uids, gids)
2. policy about the "menu" package
3. policy for architecture specification strings
4. editor/pager policy
I need more technical information about the following topics
(status: NEED-INPUT):
5. policy for MTA's file locking
6. libc6 migration
We need to discuss the following topics
(status: DISCUSSION):
7. new definition of "free software"
8. packages have to specify their source urls
9. policy for cron jobs
10. policy for devices
11. policy about including documentation
TOPIC 1: policy for user and group ids (uids, gids)
---------------------------------------------------
STATUS: NEEDS-APPROVAL
URL: http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-policy/draft/ch3.html#s3.2
INFO: The following section has been proposed. Please give me some
feedback if this can go into the Policy Manual.
3.2. Users and groups
---------------------
The Debian system can be configured to use either plain or shadow
passwords.
Some user ids (UIDs) and group ids (GIDs) are reserved globally for
use by certain packages. Because some packages need to include files
which are owned by these users or groups, or need the ids compiled
into binaries, these ids must be used on any Debian system only for
the purpose for which they are allocated. This is a serious
restriction, and we should avoid getting in the way of local
administration policies. In particular, many sites allocate users
and/or local system groups starting at 100.
Apart from this we should have dynamically allocated ids, which should
by default be arranged in some sensible order--but the behaviour
should be configurable.
No package except `base-passwd' may modify `/etc/passwd',
`/etc/shadow', or `/etc/group'.
The UID and GID ranges are as follows:
0-99:
Globally allocated by the Debian project, must be the same on
every Debian system. These ids will appear in the `passwd' and
`group' files of all Debian systems, new ids in this range being
added automatically as the `base-passwd' package is updated.
Packages which need a single statically allocated uid or gid
should use one of these; their maintainers should ask the
`base-passwd' maintainer for ids.
100-999:
Dynamically allocated system users and groups. Packages which
need a user or group, but can have this user or group allocated
dynamically and differently on each system, should use ``adduser
--system'' to create the group and/or user. adduser will check
for the existence of the user or group, and if necessary choose
an unused id based on the ranged specified in `adduser.conf'.
1000-29999:
Dynamically allocated user accounts. By default adduser will
choose uids and gids for user accounts in this range, though
`adduser.conf' may be used to modify this behaviour.
30000-59999:
Reserved.
60000-64999:
Globally allocated by the Debian project, but only created on
demand. The ids are allocated centrally and statically, but the
actual accounts are only created on users' systems on demand.
These ids are for packages which are obscure or which require
many statically-allocated ids. These packages should check for
and create the accounts in `/etc/passwd' or `/etc/group' (using
adduser if it has this facility) if necessary. Packages which are
likely to require further allocations should have a `hole' left
after them in the allocation, to give them room to grow.
65000-65533:
Reserved.
65534:
User ``nobody'.'
65535:
`(uid_t)(-1) == (gid_t)(-1)'. NOT TO BE USED, because it is the
error return sentinel value.
TOPIC 2: policy about the "menu" package
----------------------------------------
STATUS: NEEDS-APPROVAL
URL: http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-policy/draft/ch3.html#s3.2
INFO: The following section has been worked out by Joost
Witteveen, Joey Hess, and me. Please have a look at it and
tell me if that can go into the Policy Manual.
3.6. Menus
----------
The Debian `menu' packages provides a unique interface between
packages providing applications and documents, and *menu programs*
(either advanced X window managers or text-based menu programs as
pdmenu).
All packages that provide applications that need not be passed any
special command line arguments for normal operation should register a
menu entry for those applications, so that users of the `menu' package
will automatically get menu entries in their window managers, as well
in shells like `pdmenu'.
All packages that provide HTML documentation should register these
documents to the menu system, too. Check out section section 4.1, `Web
servers and applications' for details.
Please refer to the *Debian Menu System* document that comes with the
`menu' package for information about how to register your applications
and web documents.
TOPIC 3: policy for architecture specification strings
------------------------------------------------------
STATUS: NEEDS-APPROVAL
URL: (none)
INFO: There was a discussion about "arch spec strings" several
days ago. Note, that since nobody could tell me why we use
"i486-linux" in a few packages, this has been into
"i386-linux" now. If someone knows any good reasons why
"i486" is better, we should start the discussion again.
Otherwise, the following section will be included in the
next Policy Manual.
Architecture Specification Strings
----------------------------------
If a program needs to specify an "architecture specification
string" in some place, the following format has to be used:
<arch>-linux
where `<arch>' is one of the following: i386, alpha, arm, m68k,
powerpc, sparc.
Note, that we don't want to use `<arch>-debian-linux' to apply to
the rule `architecture-vendor-os' since this would make our
programs incompatible to other Linux distributions. Also note,
that we don't use `<arch>-unknown-linux', since the `unknown'
does not look very good.
TOPIC 4: editor/pager policy
------------------------------------------------------
STATUS: NEEDS-APPROVAL
URL: (none)
INFO: Ian posted a nice summary about the ``editor/pager'' policy
on debian-devel on May 9. Unfortunately, this did not get a
resolution yet. That's why I suggest the following section
for the Policy Manual. Please review it and tell me if you
agree. If there are no objections, this will get into the
next Policy Manual.
Pagers and Editors
------------------
Some programs have the ability to launch an editor or pager
program to edit or display a text document. Since there are
lots of different editors and pagers available in the Debian
distribution, the system administrator and each user should have
the possibility to choose his/her preferred editor and pager.
In addition, every program should choose a good default
editor/pager if none is selected by the user or system
administrator.
Thus, every program that launches an editor or pager should
make use of the EDITOR or PAGER environment variables to
determine the editor/pager the user wants to get started. If
these variables are not set, the programs `/usr/bin/editor'
and `/usr/bin/pager' should be used, respectively.
These two files are managed through `alternatives.' That is,
every package providing an editor or pager should call the
`update-alternatives' script to register these programs.
If it is very hard to adopt a program to make us of the EDITOR
and PAGER variable, that program should be configured to use
`/usr/bin/sensible-editor' and `/usr/bin/sensible-pager' as
editor or pager program, respectively. These are two scripts
provided in the Debian base system that check the EDITOR and
PAGER variables and launches the appropriate program or
falls back to `/usr/bin/editor' and `/usr/bin/pager',
automatically.
Since the Debian base system already provides an editor and
a pager program, there is no need for a package to depend on
`editor' and `pager', nor is it necessary for a package to
provide such virtual packages.
TOPIC 5: policy for MTA's file locking
--------------------------------------
STATUS: NEED-INPUT
The current Debian Policy (2.1.3.3) says that all mail-user-agents
(MUAs) mail-transport-agents (MTAs) have to use `dot-locking.'
However, it is known that this method is _not_ NFS safe and thus can
result in lost mail or ``other serious brain damage!''
There is one known locking mechanism that is NFS safe. Of course, it
is necessary that _all_ Debian MUAs and MTAs use _the very same_
method for locking the mail folders.
This is a very important issue and has been discussed several times on
debian-devel now, without any results. Thus, I propose to form a small
group of Debian developers that are intrested on this topic to
prepare and implement the necessary steps:
1. Adopt the section about "mail processing" in the Policy
Manual. This requires to specfiy the locking method we
want to use in some kind of ``pseudo-code.''
2. Build a shared library ``libdebian'', that contains
functions to lock, unlock, and test a file according to the
locking method we want to use. This library should simplify
the work of the MUA and MTA maintainers that need to adopt
their packages. They should link their programs against
this library and call the appropriate functions.
3. Provide Perl, Python, etc. modules/packages that implement
our locking mechanism.
4. Help the maintainers to fix their MUA/MTA packages.
TOPIC 6: libc6 migration
------------------------
STATUS: NEED-INPUT
Helmut Geyer has just posted a proposal ``RFC: libc6 policy supplement
2nd try''. This document will be distributed as ``appendix'' to the
Policy Manual if it has been approved by the Debian developers.
TOPIC 7: new definition of ``free software''
--------------------------------------------
STATUS: DISCUSSION
There was a long discussion about ``free software'' on debian-private
in the last days. If this discussion has ended and the developers
agree on such a definition, that text will be included in the Policy
Manual since all packages in the main distribution have to apply to
this.
TOPIC 8: packages have to specify their source urls
---------------------------------------------------
STATUS: DISCUSSION
It has been proposed that all packages should include some information
about where to get the upstream sources. Thus, I propose that we list
all pieces of information we want to have included in the
``/usr/doc/*/README.debian'' files.
If we have a consensus about this, we could include a ``good example''
for a ``/usr/doc/*/README.debian'' file.
I propose that the following infos are listed in this file:
- Name and email address of current Debian maintainer
- specification about where to get the upstream sources
- short description of all major changes to the program
(for example, new command line options, changed locking
mechanism, major bug fixes, etc.)
- URL of ``official home page'' if there is one (optional)
TOPIC 9: policy for cron jobs
-----------------------------
STATUS: DISCUSSION
IMHO, we should give some guidelines about how to install cron jobs,
i.e.
- don't touch /var/spool/cron/crontabs
- don't touch /etc/crontab
- you may install files in /etc/cron.{daily,weekly,monthly}
if certain rules are fulfilled (cf. bug #8814)
TOPIC 10: policy for devices
----------------------------
STATUS: DISCUSSION
We definitely need to specify a "Policy for Device Files". I'm
thinking of the following points:
- device files may _not_ be included in .debs
- device files may only be created by called the `makedev'
program in the postinst script after asked the user
- device files may _never_ be removed without asking the user
TOPIC 11: policy about including documentation
----------------------------------------------
STATUS: DISCUSSION
The current policy concerning docs is:
- HTML is the preferred format
- if the package includes docs than can be converted into HTML,
the maintainer should do so
- if the doc files are to big, they should go into a seperate
package
There are a few problems, though:
- .info files can be converted into HTML on-the-fly by the CGI
script "info2www". However, the output of ``texi2html'' is
much better. Should we ship only HTML by default and put
.info in a seperate package? (cf. bug #7890)
- how "large" may doc files be until they are moved into a
seperate package?
-- Christian Schwarz
Do you know schwarz@monet.m.isar.de, schwarz@schwarz-online.com,
Debian GNU/Linux? schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA
http://www.debian.org http://fatman.mathematik.tu-muenchen.de/~schwarz/
--
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: