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

Status of Debian Policy

The following message is a list of items to be completed for the next
version of the Debian Policy Manual. It is posted to debian-devel
periodically by the Debian Policy Manager, Christian Schwarz, to get
more feedback about certain policy issues.

Please do not quote the whole mail if you are only referring to a
single section!

This document was last modified at Time-stamp:  <97/07/06 20:31:39 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. editor/pager policy
    2. Package priorities and dependencies
    3. policy for cron jobs
    4. policy for devices
    5. why are shared libraries installed executable?
    6. app-defaults files may not be "conffiles"

I need more technical information about the following topics
(status: NEED-INPUT):

    7. policy for MTA's file locking 
    8. documentation policy
    9. new control fields
   10. perl module policy

We need to discuss the following topics
(status: DISCUSSION):


TOPIC 1: editor/pager policy
  URL:    (none)
  INFO:   I posted this to debian-devel last week and I did not
          receive any negative comments. However, I realized that
          I said "should" everywhere I wanted to say "must"! I
          fixed this in the text below. Please review it and tell me
          if you agree. If there are no objections, this will get
          into the next Policy Manual. 

     4.2. Editors and pagers

     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 has to use 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' have to be used,

     These two files are managed through `alternatives.' That is, every
     package providing an editor or pager has to 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

TOPIC 2: Package priorities and dependencies
  INFO:   As Dale reported, a few packages in the archive depend on
          other packages with a lower priority than the first. Since
          priorities are used to simplify the installation process
          this should be avoided. Therefore, I suggest to add the
          following sentence to the Policy Manual. Please review it.
          If there are no objections, it'll go into the next Policy

     Packages may not depend on packages with lower priority values. 
     If this should happen, one of the priority values will have to
     be adopted.

TOPIC 3: policy for cron jobs
  INFO:   I suggest to add the following section to the Policy Manual.
          Please have a look at it. If there are no objections, this
          will get into the next policy manual.

   Packages may not touch the configuration file /etc/crontab, nor
   may they modify the files in /var/spool/cron/crontabs .

   If a package wants to install a job that has to be executed via
   cron, it should place a file with the name if the package in one
   of the following directories:


   As these directory names say, the files within them are executed on
   a daily, weekly, or monthly basis, respectively.

   All files installed in these directories have to be scripts (shell
   scripts, Perl scripts, etc.) so that they can easily be modified
   by the local system administrator. In addition, they have to be
   registered as configuration file.

   The scripts in these directories has to check, if all necessary
   programs are installed before they try to execute them. Otherwise,
   problems will arise when a package was removed (but not purged),
   since the configuration files will be kept on the system.

TOPIC 4: policy for devices
  INFO:   I suggest to add the following section to the Policy Manual.
          Please have a look at it. If there are no objections, this
          will get into the next policy manual.

  No package may include device files in the package file tree.

  If a package needs any special device files that are not included
  in the base system, it has to call makedev in the postinst script,
  after asking the user for permission to do so.

  No package should remove any device files in the postrm or any
  other script. This is left to the system administrator.

TOPIC 5: why are shared libraries installed executable?
  INFO:   Bug #7129 asks this question. It seems, as ld.so does not
          require the libraries to be tagged `executable.' Since trying
          to "execute" a shared library results in a core dump, I 
          suggest to change the policy.
          Please have a look at the proposal below. If there are no
          objections, this will get into the next policy manual.

  Shared libraries should not be installed executable, since
  ld.so does not require this and trying to execute a shared
  library results in a core dump.

TOPIC 6: app-defaults files may not be "conffiles"
  INFO:   This policy about app-defaults files is currently used by
          lots of packages, including X. However, a few packages 
          still don't follow it (cf. bug #2717). Thus, I suggest
          to add this section to the policy manual and file bug
          reports against the packages to notify the maintainers.

  `Application defaults' files have to be installed in the
  directory /usr/X11R6/lib/X11/app-defaults/ . They are
  considered as part of the program code. Thus, they should not be
  modified and should not be tagged as `conffile.' If the local
  system administrator wants to customise X applications globally, the
  file /etc/X11/Xresources should be used.

TOPIC 7: policy for MTA's file locking
  INFO:   [I'll prepare the necesary changes to the policy and present
           them here, soon.]

TOPIC 8: documentation policy
  INFO:   [I'll prepare the necesary changes to the policy and present
           them here, soon.]

TOPIC 9: new control fields

It has been proposed that all packages include more information about
the upstream maintainer(s), URLs, license, etc.

Since dpkg and all related programs ignore all additional fields in
the control file, we can simply add a few. (This would make it much
easier for any programs that want to get these info than if they'd
have to parse a README.debian file.)

The following control fields were suggested:

     Author: name and email of main upstream author (copyright holder)
     License: code describing license type
     Original-Site: site/URL at which the package is originally stored

The "Author" field I think is important for giving due credit to whom
rightfully deserves it. Some novice Debian users might think that the
maintainer mentioned in "dpkg -I" is the author or the upstream maintainer.
That is convenient for having users contact the Debian maintainer instead
of bypassing them for the upstream author. However, I am convinced it is not
fair for the "real authors" to create this confusion. Once the package is
installed, users can check who the real author is, but they should be able
to know it from the beginning.

The License field shoud be a code taken from a list like the following:

 GPL, LGPL, BSD, Artistic: we know what they are
 PD:            public domain
 Freeware:      programs with other licenses, which are included
                in the main distribution and thus "free",
                according to Debian policy

 packages containing sources

 Non-Commercial: free use and redistribution for non-commercial purposes
 Academic: free use and redistribution for academic/research purposes
 Non-Commercial-Academic: combination of previous types
 Source-Shareware: redistribution allowed, but payment for use expected
 Tidyware: free use, redistribution only in original form or if approved
          by author

 packages without sources
 Crippleware: crippled functionality, fully functional version must be
 Demoware: time-bombed fully functional program
 Shareware: redistribution allowed, payment for use expected
 Promotional: free use for only some people or for some time only, or due to
             blatantly promotional reasons (like MSIE) 
 Shyware: free use and redistribution of binaries, sources not available

 Every other package would get "License: non-free".

 The "Original-Site" field contains the "primary URL" where you can get
 the upstream sources. If there are more than one site, the others
 should be listed in "Alternate-site-1", "Alternate-site-2", etc.

 Note, that these three additional fields _have_ to be used (if this
 becomes policy). 

TOPIC 10: perl module policy

We need to document the current "implicit" naming conventions for
Perl modules. Currently, packages containing the Perl module "foo"
are called


In addition, if a package is large (say > 200k) and contains
architecture dependent code (Perl "XS" files) the package should be
split into two:

	libfoo-perl         for arch indep stuff
	libfoo-perl-xs      for arch dep stuff

Note, that Brian S. Julin is currently working on a "debmake for
Perl modules" which simplifies the creation of Debian packages
containg Perl modules. With this, we can easily package up the
whole CPAN archive for Debian!

--                  Christian Schwarz
                     schwarz@monet.m.isar.de, schwarz@schwarz-online.com,
Debian is looking     schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
for a logo! Have a
look at our drafts     PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
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: