Attached, below, is AJ's release critical policy, in the context of
sarge.
I'm thinking we should ratify it, as is. As soon as possible.
I'm thinking we should ratify a changed document [which is more
restrictive on DFSG issues] for releases following sarge.
Objections? Flames? Constructive critisms? Other comments?
Thanks,
--
Raul
______________________________________________________________________
The purpose of this document is to be a correct, complete and canonical
list of issues that merit a "serious" bug under the clause "a severe
violation of Debian policy".
In addition to the issues listed in this document, an issue is release
critical if it:
* makes unrelated software on the system (or the whole system)
break
* causes serious data loss
* introduces a security hole on systems where you install the
packages
(these issues are "critical" severity)
* makes the package in question unusable or mostly so
* causes data loss
* introduces a security hole allowing access to the accounts
of users who use the package
(these issues are "grave" severity)
* in the maintainer's opinion, makes the package unsuitable
for release
(these issues are "serious" severity)
Further to this, certain issues may be exempted from being considered
release critical for sarge by the release manager. This is expressed
by tagging the report "sarge-ignore"; this should not be done without
explicit authorisation from the release manager.
Here's the list:
1. DFSG-freeness
Code in main and contrib must meet the DFSG, both in .debs and
in the source (including the .orig.tar.gz).
Documentation in main and contrib must be freely distributable,
and wherever possible should be under a DFSG-free license. This
will likely become a requirement post-sarge.
An exception exists for "firmware" - that is code that
will be uploaded to a hardware device as part of making it
functional. This may be distributed in main even without source
or modifications being allowed; but you must be careful not to
violate the GPL by incorporating it into a GPLed program. This
generally means using the hotplug request_firmware() interface
to load the firmware from userspace. The firmware does not need
to be moved into a separate package, however.
Everything in non-free must be distributable by Debian.
Every package must include a complete and verbatim copy of
its copyright and distribution license in its "copyright"
file. The BSD License, the Artistic License, the GPL and the
LGPL should be replaced by references to the appropriate files
in /usr/share/common-licenses. The copyright file must also
include a pointer to upstream.
The package changelog must be included.
2. Dependencies
Packages in main cannot require any software outside of main
for execution or compilation. Packages in contrib, non-free cannot
require any software in non-US.
Packages must include a "Depends:" line listing any other
packages they require for operation, unless those packages are
marked "Essential: yes". Packages must include a "Pre-Depends:"
line listing any packages required by their preinst.
If two packages cannot be installed together, one must list the other
in its "Conflicts:" field.
Essential packages must be (adequately) functional when unpacked
but not installed.
Packages listed in "Pre-Depends:" must be (adequately) functional
when unpacked but not installed.
Shared library packages must include correct shlibs files.
Debconf .config scripts must only use tools present in essential
packages.
Packages must not install programs in the default PATH with
different functionality with the same file name, even if they
Conflict:.
3. Configuration files
Packages must not modify their own or other packages conffiles
programmatically. (The only correct way to modify a conffile is
the user running an editor specifically; if anything more automated
is required or useful, configuration files must _NOT_ be handled as
conffiles)
Conffiles must be plain text.
Packages must not modify other packages' configuration files
except by an agreed upon APIs (eg, a /usr/sbin/update-foo command).
Packages' /etc/init.d scripts must be treated as configuration files.
Packages' /etc/default scripts must be treated as configuration files.
Packages must not include files in /etc/rcN.d, but must instead use
update-rc.d to indicate when their init scripts should be run.
Packages that need to install a cron job, must place a script in
/etc/cron.{daily,weekly,monthly}, or a file in /etc/cron.d. In either
case the file must be treated as a configuration file.
All configuration files must reside in /etc.
Changes to configuration files must be preserved during a package
upgrade. Configurations must be preserved on package removal, and
only deleted when the package is purged.
4. Autobuilding
Packages must list any packages they require to build beyond those
that are "build-essential" in the appropriate Build-Depends: fields.
debian/rules must be an executable makefile, beginning with the
line "#!/usr/bin/make -f" so that it can be invoked by running
the makefile rather than invoking make explicitly.
debian/rules must include the targets: clean, binary, binary-arch,
binary-indep and build; and these targets cannot require any
interaction with the user. The build target must not do anything that
requires root privileges.
Packages must autobuild without failure on all architectures on
which they are supported. Packages must be supported on as many
architectures as is reasonably possible. Packages are assumed to
be supported on all architectures for which they have previously
built successfully. Prior builds for unsupported architectures
must be removed from the archive (contact -release or ftpmaster
if this is the case).
5. General
(a) Supportable
Packages in the archive must not be so buggy or out of date we
refuse to support them.
(b) Security
Programs must be setup to use the minimum privleges they can. (ie,
not setuid where setgid will suffice; not setuid root where setuid
some other user will suffice; setuid root for the minimum period
possible, etc)
(c) File hierarchy
Packages must place all files in the locations specified by the
FHS.
Any subdirectories created in the /usr/local hierarchy must be
created and removed with mkdir and rmdir in postinst and prerm;
and the scripts must not fail if those commands fail. Packages
must not rely on the presence or absence of any files or
directories under /usr/local.
(d) UIDs
Packages must only use system uids for the purposes for which they
were allocated.
(e) Keymap
Packages must interpret keypresses and the keyboard layout
in a consistent manner (in how delete and backspace operate
for example).
(f) Libraries
Shared libraries must be compiled with -fPIC, and normally static
libraries must not be. If you need to provide static libraries
compiled with -fPIC, call it "<libname>_pic.a".
Libraries must normally be compiled with -D_REENTRANT.
Shared libraries must normally be linked with all libraries they
use symbols from.
(g) Scripts
Scripts must include the appropriate #! line, and set executable.
The package providing the script must Depend: on the appropriate
package providing the interpreter.
(h) Temporary files
Any programs and scripts that create files in /tmp or other
world writable directories must use a mechanism which fails if
the file already exists.
(i) Device files
Packages must not include device files in the .deb, but should
instead invoke MAKEDEV from postinst. Packages must not remove device
files.
(j) Log files
Log files must be rotated, preferably using /etc/logrotate.d.
Log files must be removed when the package is purged. (As such,
they shouldn't fail if the package is removed-but-not-purged,
or if the admin has deleted all the packges' logs -- check
logrotate's "missingok" directive)
(k) Editors and Pagers
Packages that need to launch an editor or pager must use the EDITOR
or PAGER environment variables if set, or fall back to /usr/bin/editor
or /usr/bin/pager.
(l) Mail
Mail programs must lock mailboxes in an NFS-safe way. MTAs must
recreate mailboxes if needed.
If setgid mail is used for locking, MUAs must avoid allowing
access to other users' mail spools.
MTAs must provide /usr/sbin/sendmail, and a symlink to that
program as /usr/lib/sendmail.
MTAs must provide a newaliases program, that makes any changes
to /etc/aliases effective.
MTAs must spool local mail to /var/mail/<user> by default.
MTAs must list the virtual package "mail-transport-agent" in their
Provides: Conflicts: and Replaces: fields.
(m) X support
Packages that can be configured to support X, must be
so configured, and must list the appropriate packages in
Depends:. Similarly when pacakges can be configured to support
gtk, gnome or kde. (Providing different versions of the package
without X or gnome/kde support should only be done when there
is a particular need)
Packages must not install files in to /usr/{bin,include,lib}/X11,
however, they should reference the files by these names in preference
to the corresponding /usr/X11R6/ directories.
(n) Games
Games may be setgid games in order to write to high score files, but
must not be setuid.
(o) Documentation
Packages must have a useful extended description.
Preformatted cat pages must not be installed.
Packages must not require the existance of any files in /usr/share/doc
in order to function.
(p) Linux Standard Base
Packages must not conflict with requirements of the LSB,
v1.3. (eg, if you provide a library specified in the LSB, you
must be compatible with the LSB specification of that library)
Basically, you should be LSB compatible. You can expect a bug
report to be filed if you're not, and if you don't know how to
fix the problem, you should email [email protected]
for assistance.
(q) Python
Packages providing python modules must comply with the python
policy (naming scheme and dependencies). See
http://people.debian.org/~joss/python-policy.txt
