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

release policy

Attached, below, is AJ's release critical policy, in the context of

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?




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)
	* causes serious data loss
	* introduces a security hole on systems where you install the
	  		(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 must not install programs in the default PATH with
	different functionality with the same file name, even if they

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

	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

  (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 debian-lsb@lists.debian.org
	for assistance.

  (q) Python

	Packages providing python modules must comply with the python
	policy (naming scheme and dependencies). See 

Reply to: