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

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.



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


This page contains links to the current version of the Policy Manual
(, the current development version ( DRAFT), and
links to related documents.


The following topics have been changed in the current development
version of the Policy Manual ( 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:

    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)
  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

     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: 

          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.

          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'.

          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.


          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.


          User ``nobody'.'

          `(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
  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

     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
  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:


     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
  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

     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',

     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
The current Debian Policy ( 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

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''

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

TOPIC 8: packages have to specify their source urls

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

IMHO, we should give some guidelines about how to install cron jobs,
     - 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

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

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

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: