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
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. 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):
(nothing)
TOPIC 1: editor/pager policy
----------------------------
STATUS: NEEDS-APPROVAL
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,
respectively.
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
packages.
TOPIC 2: Package priorities and dependencies
--------------------------------------------
STATUS: NEEDS-APPROVAL
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
Manual.
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
-----------------------------
STATUS: NEEDS-APPROVAL
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:
/etc/cron.daily
/etc/cron.weekly
/etc/cron.monthly
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
---------------------------
STATUS: NEEDS-APPROVAL
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?
-------------------------------------------------------
STATUS: NEEDS-APPROVAL
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"
--------------------------------------------------
STATUS: NEEDS-APPROVAL
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
--------------------------------------
STATUS: NEED-INPUT
INFO: [I'll prepare the necesary changes to the policy and present
them here, soon.]
TOPIC 8: documentation policy
-----------------------------
STATUS: NEED-INPUT
INFO: [I'll prepare the necesary changes to the policy and present
them here, soon.]
TOPIC 9: new control fields
---------------------------
STATUS: NEED-INPUT
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
purchased
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
----------------------------
STATUS: NEED-INPUT
We need to document the current "implicit" naming conventions for
Perl modules. Currently, packages containing the Perl module "foo"
are called
libfoo-perl
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: