--- /dev/null
+/body.tmp
+/debconf_spec/debconf_specification.html
+/debconf_spec/debconf_specification.txt.gz
+/head.tmp
+/menu-policy.html/
+/mime-policy.html/
+/perl-policy.html/
+/policy.html/
+/stamp-build
+/version.ent
+*.html.tar.gz
+*.pdf
+*.pdf.gz
+*.ps
+*.ps.gz
+*.tpt
+*.txt
+*.txt.gz
+++ /dev/null
-2006-10-02 Manoj Srivastava <srivasta@debian.org>
-
- * policy.sgml (Build-Depends):
- srivasta@debian.org--etch/debian-policy--devel--3.7--patch-26
- Fix spelling error in "dependency"
-
-2006-06-20 Manoj Srivastava <srivasta@debian.org>
-
- * policy.sgml:
- srivasta@debian.org--etch/debian-policy--devel--3.7--patch-21
- Fix FSF email address
- Text Documentation --> Plain text documentation, since
- the meaning appeared unclear.
-
- * perl-policy.sgml:
- srivasta@debian.org--etch/debian-policy--devel--3.7--patch-24
- Fix FSF email address
-
- * menu-policy.sgml:
- srivasta@debian.org--etch/debian-policy--devel--3.7--patch-24
- Fix FSF email address
-
- * mime-policy.sgml:
- srivasta@debian.org--etch/debian-policy--devel--3.7--patch-24
- Fix FSF email address
-
-2006-06-19 Manoj Srivastava <srivasta@debian.org>
-
- * upgrading-checklist.html (issue):
- srivasta@debian.org--etch/debian-policy--devel--3.7--patch-20
- Typo fixes.
-
- * policy.sgml (INSTALL_DIR):
- srivasta@debian.org--etch/debian-policy--devel--3.7--patch-20
- typo fix: s/s/a/
- Add "is"
- Clarify the fact that most fields can have multi line
- values in control files, apart from the Uploaders field.
- Since the packaging system can handle multi line fields
- anyway, it does not make sense to prohibit them in
- policy.
- Mention the need to have a copyright file in the source
- package section as well.
-
-2006-05-03 Manoj Srivastava <srivasta@debian.org>
-
- * policy.sgml (INSTALL_DIR):
- srivasta@debian.org--etch/debian-policy--devel--3.7--patch-17
- Clarified when it may be reasonable to violate the
- standard directive that shared libraries must be
- compiled with -fPIC, and static libraries without,
- added the protocol to be followed when doing so.
-
-2006-04-26 Manoj Srivastava <srivasta@debian.org>
-
- * policy.sgml:
- srivasta@debian.org--etch/debian-policy--devel--3.7--patch-14
- Added an informative footnote to document the fact that
- while dpkg does handle changes to file
- ownership/permissions on upgrade, ownership or
- permissions on directories already on the system are not
- modified.
- (Version): Disambiguate the overloaded use of section for main,
- contrib, non-free as well as for admin, lib,devel,
- etc. Various fixes based on a 1999 nit picking message
- from Joey Hess
-
-2006-04-25 Manoj Srivastava <srivasta@debian.org>
-
- * policy-process.sgml:
- srivasta@debian.org--etch/debian-policy--devel--3.6--patch-16
- Minor typo fix
-
- * upgrading-checklist.html (issue):
- srivasta@debian.org--etch/debian-policy--devel--3.6--patch-15
- Document the fact that cgi executable location is
- changing, and that web servers need to provide script
- aliases.
- (issue):
- srivasta@debian.org--etch/debian-policy--devel--3.6--patch-15
- mentioned the change to FHS 2.3
- (issue):
- srivasta@debian.org--etch/debian-policy--devel--3.6--patch-15
- When scripts are installed into into a directory in the
- system PATH, the script name should not include
- aextension that denotes the scripting language currently
- used to implement it.
-
- * policy.sgml (http):
- srivasta@debian.org--etch/debian-policy--devel--3.6--patch-15
- [PENDING AMENDMENT 20/01/2000] Splitting cgi-bin. Since
- most web servers do include this, it seems like it is
- about time.
- (Version):
- srivasta@debian.org--etch/debian-policy--devel--3.6--patch-15
- Changed the default version we refer to in
- policy to version 2.3, and added in specific
- exceptions t the new version of the FHS.
- (Package):
- srivasta@debian.org--etch/debian-policy--devel--3.6--patch-15
- Mention that all fileds, except the Uploaders, are
- supposed to be a single logical line, which may be
- spread over multiple physical lines (newline followed by
- space is elided). Also mention that anything parsing
- the control file must allow for a multi-line uploaders
- field.
- (INSTALL_DIR):
- srivasta@debian.org--etch/debian-policy--devel--3.6--patch-15
- When scripts are installed into into a directory in the
- system PATH, the script name should not include an
- extensionthat denotes the scripting language currently
- used to implement it.
- No longer specify the full list of common license
- files,since the list gets out dated with newer
- versions of license files.
- Punt to dpkg-architecture to providing legal
- architecture strings, since that's what is used
- by everyone anyway. The version in policy was
- wrong, but that s=does not seem to have
- hindered anyone, which indicates that this
- policy directive was uneeded. Now the
- dpkg-architecture list is deemed authoritative,
- which it is, and the format is in an
- informative foot note.
- Make use of invoke-rc.d mandatory when calling initscripts.
- Changed various X related paths to reflect the move over
- to Xorg, and away from /usr/X11R6.
-
-2005-12-26 Manoj Srivastava <srivasta@debian.org>
-
- * policy.sgml:
- srivasta@debian.org--etch/debian-policy--devel--3.6--patch-6
- Mention config files, with a proper reference in the
- maintainer scripts area
-
-2005-12-24 Manoj Srivastava <srivasta@debian.org>
-
- * perl-policy.sgml:
- srivasta@debian.org--etch/debian-policy--devel--3.6--patch-8
- Typo fix (as -> at)
-
- * policy.sgml:
- srivasta@debian.org--etch/debian-policy--devel--3.6--patch-6
- Policy does not describe the current tasksel/tasks
- situation very well. After correctiong the errors, and
- eliminating obsolete paragraphs, therewas nothing that a
- general maintainer needs to do about tasksel task
- selection, it makes no sense to have this section in
- policy. removed.
- One of the examples listed in B.1 is not correct and
- does not work. Three problems. One is that 'xof' does
- not write to stdout, 'xOf' does. Another is
- that filenames in debs start with "./" and so
- the listed file will not be matched. Third is
- that f needs a filename and "-" is usually the
- tradition, but hyphen problems with fonts
- probably caused it to be dropped. That last
- probably needs a special crosscheck to make sure
- it makes it through the formatting.
- (INSTALL):
- srivasta@debian.org--etch/debian-policy--devel--3.6--patch-6
- typo fix.
- Fixed up the description, and summary, of the maintainer
- scripts call sequence.
- remove obsolete footnote statements about UTF-8
- Erase mention of obsolete non-US section
- (Package):
- srivasta@debian.org--etch/debian-policy--devel--3.6--patch-6
- The format field of .dsc is now mandatory
-
-2005-06-18 Manoj Srivastava <srivasta@debian.org>
-
- * virtual-package-names-list.txt (Format):
- srivasta@debian.org--etch/debian-policy--devel--3.6--patch-5
- Added x-session-manager
- (Format):
- srivasta@debian.org--etch/debian-policy--devel--3.6--patch-5
- Added the section on Scheme and interpreters, which
- includes: scheme-r4rs scheme-r5rs scheme-ieee-11878-1900
- scheme-srfi-0 scheme-srfi-7 scheme-srfi-55
- (Format):
- srivasta@debian.org--etch/debian-policy--devel--3.6--patch-5
- Added x-display-manager
-
- * upgrading-checklist.html (issue):
- srivasta@debian.org--etch/debian-policy--devel--3.6--patch-4
- Fixed a type (missing /)
-
-2005-06-16 Manoj Srivastava <srivasta@debian.org>
-
- * upgrading-checklist.html (issue):
- srivasta@debian.org--etch/debian-policy--devel--3.6--patch-1
- Document the fact that HTTP servers are recommended to
- provide an /image alias for packages to share images
- with the server.
-
- * policy.sgml (http):
- srivasta@debian.org--etch/debian-policy--devel--3.6--base-0
- The proposal states that /usr/share/images/<package> and
- can be referred to as
- http://localhost/images/<package>/<filename. This allows
- a simple solution to making images in packages
- accessible to the HTTP server without having to resort
- to symbolic links.
-
- Various spelling errors were also corrected in a spell
- check run.
-
- Provide the URL for the down-loadable version of policy
- documents in various formats, instead of just providing
- a link.
-
- * virtual-package-names-list.txt (Format):
- srivasta@debian.org--etch/debian-policy--devel--3.6--base-0
- Removed aspell-dictionary, as requested by the package
- maintainers, as it is no longer in use.
-
So, what do we need to store in a variable template? Of course we
need a name to identify the template. Template names are made up of
components separated by the character `/' (slash).
- Each component is limited to alphanumerics and `+' `-' `.'
- (plus, minus, full stop).
+ Each component is limited to alphanumerics and `+' `-' `.' `_'
+ (plus, minus, full stop, underscore).
</para>
<para>
A type is also needed so data can be verified. Here is a table
+++ /dev/null
-Document: debian-policy-process
-Title: Debian Policy Process Description
-Author: The Debian Policy Mailing list
-Abstract: This document describes how Debian Policy is developed.
-Section: Debian
-
-Format: debiandoc-sgml
-Files: /usr/share/doc/debian-policy/policy-process.sgml.gz
-
-Format: text
-Files: /usr/share/doc/debian-policy/policy-process.txt.gz
-
-Format: HTML
-Index: /usr/share/doc/debian-policy/policy-process.html/index.html
-Files: /usr/share/doc/debian-policy/policy-process.html/*.html
+++ /dev/null
-2006-06-19 Manoj Srivastava <srivasta@debian.org>
-
- * control (Build-Depends-Indep):
- srivasta@debian.org--etch/debian-policy--devel--3.7--patch-20
- use elinks as an alternate build-dependency instead of
- links-ssl
-
-debian-policy (3.7.4.0) unstable; urgency=low
+debian-policy (3.8.1.0) unstable; urgency=low
+
+ * Policy: Clarify what "sensible behavior" is for init scripts
+ Wording: Steve Langasek <vorlon@debian.org>
+ Seconded: Raphaël Hertzog <hertzog@debian.org>
+ Seconded: Russ Allbery <rra@debian.org>
+ Closes: #426877
+ * Policy: Remove alternative changelog formats from main manual
+ Wording: Russ Allbery <rra@debian.org>
+ Seconded: Ben Pfaff <blp@cs.stanford.edu>
+ Seconded: Guillem Jover <guillem@debian.org>
+ Closes: #489460
+ * Policy: Mandate UTF-8 for changelog files
+ Wording: Russ Allbery <rra@debian.org>
+ Seconded: Guillem Jover <guillem@debian.org>
+ Seconded: Kurt Roeckx <kurt@roeckx.be>
+ Closes: #241333
+ * Policy: Mandate UTF-8 for control files
+ Wording: Russ Allbery <rra@debian.org>
+ Seconded: Kurt Roeckx <kurt@roeckx.be>
+ Seconded: Raphaël Hertzog <hertzog@debian.org>
+ Closes: #143941
+ * Policy: New option in DEB_BUILD_OPTIONS to avoid running test-suites
+ Wording: Russ Allbery <rra@debian.org>
+ Seconded: Guillem Jover <guillem@debian.org>
+ Seconded: Raphaël Hertzog <hertzog@debian.org>
+ Closes: #416450
+ * Policy: Expand expected capabilities for local in /bin/sh scripts
+ Wording: Russ Allbery <rra@debian.org>
+ Seconded: Guillem Jover <guillem@debian.org>
+ Seconded: Raphaël Hertzog <hertzog@debian.org>
+ Closes: #473019
+ * Policy: Clarify Essential definition and caution when adding to it
+ Wording: Russ Allbery <rra@debian.org>
+ Seconded: Jörg Sommer <joerg@alea.gnuu.de>
+ Seconded: Guillem Jover <guillem@debian.org>
+ Closes: #479080
+ * Policy: Allow user mail spools to be mode 0600 or 0660
+ Wording: Russ Allbery <rra@debian.org>
+ Seconded: Kurt Roeckx <kurt@roeckx.be>
+ Seconded: Andrew McMillan <awm@debian.org>
+ Closes: #470994
+ * Policy: Remove special handling of init scripts ending in .sh
+ Wording: Kel Modderman <kel@otaku42.de>
+ Seconded: Russ Allbery <rra@debian.org>
+ Seconded: Henrique de Moraes Holschuh <hmh@debian.org>
+ Closes: #513955
+ * Policy: /var/run and /var/lock may be volatile
+ Wording: Colin Watson <cjwatson@debian.org>
+ Seconded: Russ Allbery <rra@debian.org>
+ Seconded: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>
+ Closes: #514326
+ * Policy: debian/control allows comments starting with #
+ Wording: Russ Allbery <rra@debian.org>
+ Seconded: Julien Cristau <jcristau@debian.org>
+ Seconded: Adeodato Simó <dato@net.com.org.es>
+ Seconded: Guillem Jover <guillem@debian.org>
+ Closes: #446712
+ * Improve the documentation of maintainer script actions for diversions
+ in the informative appendix to allow for addition of a new diversion
+ on upgrade and handle error cases correctly. Thanks to Olivier Berger
+ for the report and Raphaël Hertzog for the review. (Closes: #483418)
+ * Clarify the meaning of architecture restrictions on build dependencies
+ in the presence of alternatives. Thanks to Guillem Jover for the
+ explanation and review and Emilio Pozuelo Monfort and Don Armstrong
+ for wording review. (Closes: #163666)
+ * Change the term "category" to "archive area" when referring to main,
+ contrib, and non-free. This is closer to the wording of the Social
+ Contract. (Closes: #473439)
+ * Use <user>:<group> notation rather than <user>.<group> notation in
+ multiple places. Thanks, Kurt Roeckx. (Closes: #488039)
+ * Fix typo in 3.8.0.0 upgrading-checklist entry. Patch from Kobayashi
+ Noritada. (Closes: #487701)
+ * Mention debugging packages as an explicit example of packages with
+ extra priority. Thanks, Charles Plessy. (Closes: #491985)
+ * Clarify that translation is only required for user-visible debconf
+ messages. Capitalize "Debian Configuration Management Specification"
+ uniformly. Thanks, Julian Andres Klode. (Closes: #492624)
+ * Add --wildcards to the sample tar command in appendix B.1 for
+ extracting the package copyright file, adjusting for new tar option
+ behavior. Thanks, Yan Morin. (Closes: #503685)
+ * Reword the requirement that maintainer scripts exit with a zero
+ status on success to avoid double-negatives.
+ * Include the full name of each menu category rather than only the
+ portion relative to the parent heading to be clearer in long category
+ lists. Thanks, Christoph Berg. (Closes: #511804)
+ * Build-Depend on texlive rather than tetex-extra. texlive appears to
+ be sufficient for how Policy uses debiandoc-sgml and pulls in far
+ fewer packages.
+ * Remove the postinst and prerm scripts. doc-base registration is now
+ handled by triggers and no longer required and removal of /usr/doc
+ links was completed long ago.
+ * Reference GPL-2 rather than the GPL symlink in debian/copyright.
+
+ -- Russ Allbery <rra@debian.org> Wed, 11 Mar 2009 20:50:52 -0700
+
+debian-policy (3.8.0.1) unstable; urgency=low
+
+ * Don't attempt to register the non-existent debian-policy-process
+ document. Thanks, Adrian von Bidder. (Closes: #484706)
+
+ -- Russ Allbery <rra@debian.org> Thu, 05 Jun 2008 13:13:01 -0700
+
+debian-policy (3.8.0.0) unstable; urgency=low
* Bug fix: "[PROPOSAL] "debian/README.source" file for packages with
non-trivial source", thanks to Wouter Verhelst, Jörg Sommer, Colin Watson,
(Closes: #65577).
* Bug fix: "scripts as configuration files: should vs. must", thanks to Frank
Küster (Closes: #403391).
+ * Bug fix: "debconf specification should allow underscores in template
+ names", thanks to Colin Watson (Closes: #473761).
+ * Bug fix: "clarify handling of run-time and compile-time support programs",
+ thanks to Goswin Brederlow and Raphael Hertzog (Closes: #367984).
+ * Policy: better document version ranking and empty Debian revisions
+ Wording: Russ Allbery <rra@debian.org>
+ Seconded: Raphaël Hertzog <hertzog@debian.org>
+ Seconded: Manoj Srivastava <srivasta@debian.org>
+ Seconded: Guillem Jover <guillem@debian.org>
+ Closes: #186700, #458910
+ * Policy: remove obsolete app-defaults and Xresources provisions
+ Wording: Julien Cristau <jcristau@debian.org>
+ Seconded: Russ Allbery <rra@debian.org>
+ Closes: #480551
* Bug fix: "Examples of dpkg frontends should mention apt now", thanks
to Josh Triplett (Closes: #455602).
* Bug fix: "Minor typos and wording suggestions", thanks to Michael
Tautschnig (Closes: #422552).
+ * Bug fix: "substvar reference moved from dpkg-source(1) to
+ deb-substvars(5)", thanks to Ian Beckwith (Closes: #475731).
+ * Policy: bugs fixed in NMUs are now closed rather than marked fixed
+ Wording: Russ Allbery <rra@debian.org> (thanks, Sandro Tosi)
+ Closes: #481640
+ * Policy: C.1.4, C.1.8: minor typos
+ Wording: Sandro Tosi <matrixhasu@gmail.com>
+ Closes: #481954
+ * Remove the now-obsolete policy-process document.
* Add an md5sums control file.
+ * Add Vcs-Browser and Vcs-Git control fields.
* Remove build system support for FHS 2.1 and FSSTND, mostly commented out.
+ * Remove more temporary files created by the build.
* Remove the FSSTND license from debian/copyright; no FSSTND files are
currently part of policy.
* Update FHS copyright dates in debian/copyright.
* Standardize the spacing around headings in upgrading-checklist.html.
+ * Remove old ChangeLog files and metadata headers in maintainer scripts
+ and debian/rules.
- --
+ -- Russ Allbery <rra@debian.org> Wed, 04 Jun 2008 15:53:27 -0700
debian-policy (3.7.3.0) unstable; urgency=low
Priority: optional
Maintainer: Debian Policy List <debian-policy@lists.debian.org>
Uploaders: Manoj Srivastava <srivasta@debian.org>, Russ Allbery <rra@debian.org>
-Standards-Version: 3.7.3
-Build-Depends-Indep: sgml-data (>= 2.0), debiandoc-sgml (>= 1.1.47), tetex-extra, groff, bsdmainutils, pstoedit, jade, docbook-xml (>= 3.1.1), docbook-dsssl, tidy, links (>= 0.90) | elinks
+Standards-Version: 3.8.0
+Build-Depends-Indep: sgml-data (>= 2.0), debiandoc-sgml (>= 1.1.47), texlive, groff, bsdmainutils, pstoedit, jade, docbook-xml (>= 3.1.1), docbook-dsssl, tidy, links (>= 0.90) | elinks
+Vcs-Browser: http://git.debian.org/?p=dbnpolicy/policy.git
+Vcs-Git: git://git.debian.org/git/dbnpolicy/policy.git
Package: debian-policy
Architecture: all
for more details.
You should have received a copy of the GNU General Public License with
-your Debian GNU/Linux system, in /usr/share/common-licenses/GPL, or
+your Debian GNU/Linux system, in /usr/share/common-licenses/GPL-2, or
with the dpkg source package as the file COPYING. If not, write to the
Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
MA 02110-1301 USA
+++ /dev/null
-#!/bin/sh
-# -*- Mode: Sh -*-
-# postinst ---
-# Author : Manoj Srivastava ( srivasta@tiamat.datasync.com )
-# Created On : Thu Oct 29 15:23:36 1998
-# Created On Node : tiamat.datasync.com
-# Last Modified By : Manoj Srivastava
-# Last Modified On : Fri Mar 7 13:32:56 2003
-# Last Machine Used: glaurung.green-gryphon.com
-# Update Count : 10
-# Status : Unknown, Use with caution!
-# HISTORY :
-# Description :
-#
-#
-
-
-# Abort if any command returns an error value
-set -e
-
-# This is filled in by debian/rules
-PACKAGE=#PACKAGE#
-
-# This script is called as the last step of the installation of the
-# package. All the package's files are in place, dpkg has already done
-# its automatic conffile handling, and all the packages we depend of
-# are already fully installed and configured.
-
-package_name=#PACKAGE#
-
-if [ -z "package_name" ]; then
- print >&2 "Internal Error. Please report a bug."
- exit 1;
-fi
-
-#perl -e 'print readlink("/usr/doc/'$package_name'"), "\n"; '
-case "$1" in
- configure)
- # Configure this package. If the package must prompt the user for
- # information, do it here.
-
- if [ -x /usr/sbin/install-docs ]; then
- /usr/sbin/install-docs -i /usr/share/doc-base/debian-policy
- /usr/sbin/install-docs -i /usr/share/doc-base/debian-menu-policy
- /usr/sbin/install-docs -i /usr/share/doc-base/debian-mime-policy
- /usr/sbin/install-docs -i /usr/share/doc-base/debian-perl-policy
- /usr/sbin/install-docs -i /usr/share/doc-base/debian-policy-process
- /usr/sbin/install-docs -i /usr/share/doc-base/debconf-spec
- /usr/sbin/install-docs -i /usr/share/doc-base/fhs
- fi
-
- # There are three sub-cases:
- if test "${2+set}" != set; then
- # We're being installed by an ancient dpkg which doesn't remember
- # which version was most recently configured, or even whether
- # there is a most recently configured version.
- :
-
- elif test -z "$2" || test "$2" = "<unknown>"; then
- # The package has not ever been configured on this system, or was
- # purged since it was last configured.
- :
-
- else
- # Version $2 is the most recently configured version of this
- # package.
- :
-
- fi
-
-
- ;;
- abort-upgrade)
- # Back out of an attempt to upgrade this package FROM THIS VERSION
- # to version $2. Undo the effects of "prerm upgrade $2".
- :
-
- ;;
- abort-remove)
- if test "$2" != in-favour; then
- echo "$0: undocumented call to \`postinst $*'" 1>&2
- exit 0
- fi
- # Back out of an attempt to remove this package, which was due to
- # a conflict with package $3 (version $4). Undo the effects of
- # "prerm remove in-favour $3 $4".
- :
-
- ;;
- abort-deconfigure)
- if test "$2" != in-favour || test "$5" != removing; then
- echo "$0: undocumented call to \`postinst $*'" 1>&2
- exit 0
- fi
- # Back out of an attempt to deconfigure this package, which was
- # due to package $6 (version $7) which we depend on being removed
- # to make way for package $3 (version $4). Undo the effects of
- # "prerm deconfigure in-favour $3 $4 removing $6 $7".
- :
-
- ;;
- *) echo "$0: didn't understand being called with \`$1'" 1>&2
- exit 0;;
-esac
-
-exit 0
+++ /dev/null
-#!/bin/sh
-# -*- Mode: Sh -*-
-# prerm ---
-# Author : Manoj Srivastava ( srivasta@tiamat.datasync.com )
-# Created On : Thu Oct 29 15:31:03 1998
-# Created On Node : tiamat.datasync.com
-# Last Modified By : Manoj Srivastava
-# Last Modified On : Fri Mar 17 17:10:23 2000
-# Last Machine Used: glaurung.green-gryphon.com
-# Update Count : 2
-# Status : Unknown, Use with caution!
-# HISTORY :
-# Description :
-#
-#
-
-# Abort if any command returns an error value
-set -e
-
-# This is filled in by debian/rules
-package_name=#PACKAGE#
-
-# This script is called as the first step in removing the package from
-# the system. This includes cases where the user explicitly asked for
-# the package to be removed, upgrade, automatic removal due to conflicts,
-# and deconfiguration due to temporary removal of a depended-on package.
-
-case "$1" in
- remove)
- # This package about to be removed.
- :
- if [ -L /usr/doc/$package_name ]; then
- rm -f /usr/doc/$package_name
- fi
-
- # There are two sub-cases:
- if test "${2+set}" = set; then
- if test "$2" != in-favour; then
- echo "$0: undocumented call to \`prerm $*'" 1>&2
- exit 0
- fi
- # We are being removed because of a conflict with package $3
- # (version $4), which is now being installed.
- :
-
- else
- # The package is being removed in its own right.
- :
-
- fi ;;
- deconfigure)
- if test "$2" != in-favour || test "$5" != removing; then
- echo "$0: undocumented call to \`prerm $*'" 1>&2
- exit 0
- fi
- # Package $6 (version $7) which we depend on is being removed due
- # to a conflict with package $3 (version $4), and this package is
- # being deconfigured until $6 can be reinstalled.
- :
-
- ;;
- upgrade)
- # Prepare to upgrade FROM THIS VERSION of this package to version $2.
- :
- if [ -L /usr/doc/$package_name ]; then
- rm -f /usr/doc/$package_name
- fi
-
- ;;
- failed-upgrade)
- # Prepare to upgrade from version $2 of this package TO THIS VERSION.
- # This is only used if the old version's prerm couldn't handle it,
- # and returned non-zero. (Fix old prerm bugs here.)
- :
-
- ;;
- *) echo "$0: didn't understand being called with \`$1'" 1>&2
- exit 0;;
-esac
-
-
-
-if [ -x /usr/sbin/install-docs ]; then
- /usr/sbin/install-docs -r debian-policy
- /usr/sbin/install-docs -r debian-menu-policy
- /usr/sbin/install-docs -r debian-mime-policy
- /usr/sbin/install-docs -r debian-perl-policy
- /usr/sbin/install-docs -r debian-policy-process
- /usr/sbin/install-docs -r debconf-spec
- /usr/sbin/install-docs -r fhs
-fi
-
-exit 0
#!/usr/bin/make -f
-############################ -*- Mode: Makefile -*- ###########################
-## rules ---
-## Author : Manoj Srivastava ( srivasta@tiamat.datasync.com )
-## Created On : Thu Oct 29 15:35:55 1998
-## Created On Node : tiamat.datasync.com
-## Last Modified By : Manoj Srivastava
-## Last Modified On : Tue Oct 26 15:20:25 2004
-## Last Machine Used: glaurung.internal.golden-gryphon.com
-## Update Count : 62
-## Status : Unknown, Use with caution!
-## HISTORY :
-## Description :
-## $Id$
-###############################################################################
ifdef ARCH
ha:=-a$(ARCH)
sanitycheck := debian/rules policy.sgml
-SGML_FILES := policy menu-policy mime-policy policy-process perl-policy
+SGML_FILES := policy menu-policy mime-policy perl-policy
DESC_FILES := debian-policy debian-menu-policy debian-perl-policy \
- debian-mime-policy debian-policy-process debconf-spec fhs
+ debian-mime-policy debconf-spec fhs
# While we have two versions of the FHS installed in the source package,
# we need to modify this to handle it. This is the easiest way to do it.
$(SGML_FILES:=.txt.gz) $(SGML_FILES:=.html.tar.gz) \
policy.pdf.gz policy.ps.gz \
debconf_specification.xml.tar.gz \
- policy.pdf policy.ps policy.txt policy.
+ policy.pdf policy.ps policy.txt policy. \
+ body.tmp head.tmp policy.tpt
STAMPS_TO_CLEAN := stamp-policy stamp-build
DIRS_TO_CLEAN := debian/tmp fhs $(SGML_FILES:=.html)
@set -ex; \
cd debian/tmp; \
find . -type f -printf '%P\0' | xargs -r0 md5sum > DEBIAN/md5sums
- sed -e 's/#PACKAGE#/$(package)/g' debian/postinst.in > debian/postinst
- sed -e 's/#PACKAGE#/$(package)/g' debian/prerm.in > debian/prerm
- $(install_program) debian/postinst debian/tmp/DEBIAN/
- $(install_program) debian/prerm debian/tmp/DEBIAN/
dpkg-gencontrol -p$(package) -Pdebian/tmp -isp
chown -R root:root debian/tmp
chmod -R go=rX debian/tmp
<item>
<p>Normal applications</p>
<p><taglist>
- <tag>Accessibility</tag>
+ <tag>Applications/Accessibility</tag>
<item>
<p>Tools to aid people with disabilities or for machines
lacking usual input devices.</p>
<p>Examples: gok, yasr, dasher.</p>
</item>
- <tag>Amateur Radio</tag>
+ <tag>Applications/Amateur Radio</tag>
<item>
<p>Anything relating to HAM radio.</p>
<p>Examples: baken, hamsoft, twlog</p>
</item>
- <tag>Data Management</tag>
+ <tag>Applications/Data Management</tag>
<item>
<p>Interactive database programs, collection managers,
address books, bibliography tools, etc.</p>
<p>gaby, alexandria, mdbtools</p>
</item>
- <tag>Editors</tag>
+ <tag>Applications/Editors</tag>
<item>
<p>Editors, other than office word processors, for
text-based information.</p>
<p>Examples: ksubtile, nano, hexedit</p>
</item>
- <tag>Education</tag>
+ <tag>Applications/Education</tag>
<item>
<p>Educational and training softwares.</p>
<p>Examples: gtypist, gcompris, quiz</p>
</item>
- <tag>Emulators</tag>
+ <tag>Applications/Emulators</tag>
<item>
<p>Software that allows you to run non-native
software or more than one OS at a time.</p>
<p>Examples: wine, dosemu, qemu</p>
</item>
- <tag>File Management</tag>
+ <tag>Applications/File Management</tag>
<item>
<p>Tools for file management, archiving,
searching, CD/DVD burning, backup, etc.</p>
<p>Examples: file-roller, mc, baobab</p>
</item>
- <tag>Graphics</tag>
+ <tag>Applications/Graphics</tag>
<item>
<p>2D and 3D graphics manipulation software.</p>
<p>Examples: gimp, inkscape, imagemagick</p>
</item>
- <tag>Mobile Devices</tag>
+ <tag>Applications/Mobile Devices</tag>
<item>
<p>Software that allows you to interface with mobile
devices (phones, PDAs, etc.).</p>
<p>Examples: kandy, gnokii, gnome-pilot</p>
</item>
- <tag>Network</tag>
+ <tag>Applications/Network</tag>
<item>
Network related software. This is a three-level
section, do not put entries directly here.
<taglist>
- <tag>Communication</tag>
+ <tag>Applications/Network/Communication</tag>
<item>
<p>Mail, USENET news, chat, instant messaging,
IP telephony, video conferencing software, etc.</p>
<p>Examples: xchat, gaim, mutt</p>
</item>
- <tag>File Transfer</tag>
+ <tag>Applications/Network/File Transfer</tag>
<item>
<p>File transfer software such as download
managers, FTP clients, P2P clients, etc.</p>
<p>Examples: amule, gftp, d4x</p>
</item>
- <tag>Monitoring</tag>
+ <tag>Applications/Network/Monitoring</tag>
<item>
<p>Network monitoring software</p>
<p>Examples: gip, ettercap, iptstate</p>
</item>
- <tag>Web Browsing</tag>
+ <tag>Applications/Network/Web Browsing</tag>
<item>
<p>Web browsers, tools for offline browsing, etc.</p>
<p>Examples: elinks, epiphany-browser, webhttrack</p>
</item>
- <tag>Web News</tag>
+ <tag>Applications/Network/Web News</tag>
<item>
<p>Web feed (RSS, Atom, etc.) and podcast aggregators.
</p>
</item>
</taglist>
</item>
- <tag>Office</tag>
+ <tag>Applications/Office</tag>
<item>
<p>Office suites, word processors, spreadsheets,
CRM, ERP, financial sofware, etc.</p>
<p>Examples: openoffice.org, tinyerp-client, gnucash</p>
</item>
- <tag>Programming</tag>
+ <tag>Applications/Programming</tag>
<item>
<p>IDEs, debuggers, etc.</p>
<p>Examples: anjuta, gdb, eclipse</p>
</item>
- <tag>Project Management</tag>
+ <tag>Applications/Project Management</tag>
<item>
<p>Timetable managers, group task trackers,
bug tracking software, etc.</p>
<p>Examples: planner, bugzilla, gnotime</p>
</item>
- <tag>Science</tag>
+ <tag>Applications/Science</tag>
<item>
Scientific and engineering-related software.
<taglist>
- <tag>Astronomy</tag>
+ <tag>Applications/Science/Astronomy</tag>
<item>
<p>Astronomy-related software.</p>
<p>Examples: celestia, spacechart, stellarium</p>
</item>
- <tag>Biology</tag>
+ <tag>Applications/Science/Biology</tag>
<item>
<p>Biology-related software.</p>
<p>Examples: arb, ncbi-tools-x11, seaview</p>
</item>
- <tag>Chemistry</tag>
+ <tag>Applications/Science/Chemistry</tag>
<item>
<p>Chemistry-related software.</p>
<p>Examples: chemtool, kalzium, xdrawchem</p>
</item>
- <tag>Data Analysis</tag>
+ <tag>Applications/Science/Data Analysis</tag>
<item>
<p>Software designed for processing, extracting,
and presenting generic scientific data.</p>
<p>Examples: fityk, ygraph, mn-fit</p>
</item>
- <tag>Electronics</tag>
+ <tag>Applications/Science/Electronics</tag>
<item>
<p>Circuit design tools, simulators and
assemblers for microprocessors, etc</p>
<p>Examples: geda, gnucap, tkgate</p>
</item>
- <tag>Engineering</tag>
+ <tag>Applications/Science/Engineering</tag>
<item>
<p>CAD, UML tools, diagram-drawing and
other engineering-related software.</p>
<p>Examples: tcm, dia, qcad</p>
</item>
- <tag>Geoscience</tag>
+ <tag>Applications/Science/Geoscience</tag>
<item>
<p>Geoscience-related software.</p>
<p>Examples: earth3d, qgis, therion</p>
</item>
- <tag>Mathematics</tag>
+ <tag>Applications/Science/Mathematics</tag>
<item>
<p>Mathematics-related software.</p>
<p>Examples: gcalctool, snappea, xeukleides</p>
</item>
- <tag>Medicine</tag>
+ <tag>Applications/Science/Medicine</tag>
<item>
<p>Medicine-related software.</p>
<p>Examples: mssstest, gnumed-client, xmedcon</p>
</item>
- <tag>Physics</tag>
+ <tag>Applications/Science/Physics</tag>
<item>
<p>Physics-related software.</p>
<p>Examples: kxterm, ifrit, paw</p>
</item>
- <tag>Social</tag>
+ <tag>Applications/Science/Social</tag>
<item>
<p>Social sciences-related software.</p>
<p>Examples: gnomesword, hanzim, bibletime</p>
</item>
</taglist>
</item>
- <tag>Shells</tag>
+ <tag>Applications/Shells</tag>
<item>
<p>Various shells to be used inside a terminal emulator.</p>
<p>Examples: bash, ksh, zsh</p>
</item>
- <tag>Sound</tag>
+ <tag>Applications/Sound</tag>
<item>
<p>Sound players, editors, and rippers/recorders.</p>
<p>Examples: beep-media-player, grip, audacity</p>
</item>
- <tag>System</tag>
+ <tag>Applications/System</tag>
<item>
System related software.
<taglist>
- <tag>Administration</tag>
+ <tag>Applications/System/Administration</tag>
<item>
<p>Administrative and system configuration utilities,
also tools for personal user settings.</p>
<p>Examples: gnome-control-center, configure-debian, gksu</p>
</item>
- <tag>Hardware</tag>
+ <tag>Applications/System/Hardware</tag>
<item>
<p>Tools for manipulating specific hardware,
especially non-standard laptop hardware.</p>
<p>Examples: toshutils, nvclock-gtk, nvtv</p>
</item>
- <tag>Language Environment</tag>
+ <tag>Applications/System/Language Environment</tag>
<item>
<p>This section is reserved for language-env as a
special case.</p>
</item>
- <tag>Monitoring</tag>
+ <tag>Applications/System/Monitoring</tag>
<item>
<p>System information and monitoring tools, log viewers,
etc.</p>
<p>Examples: top, hal-device-manager, gtkdiskfree</p>
</item>
- <tag>Package Management</tag>
+ <tag>Applications/System/Package Management</tag>
<item>
<p>Package managers and related tools.</p>
<p>Examples: aptitude, deborphan, smartpm</p>
</item>
- <tag>Security</tag>
+ <tag>Applications/System/Security</tag>
<item>
<p>Security, cryptography and privacy related software,
antiviruses, tools to track and report bugs, etc.</p>
</item>
</taglist>
</item>
- <tag>Terminal Emulators</tag>
+ <tag>Applications/Terminal Emulators</tag>
<item>
<p>Graphical terminal emulators.</p>
<p>Examples: xterm, gnome-terminal, rxvt</p>
</item>
- <tag>Text</tag>
+ <tag>Applications/Text</tag>
<item>
<p>Text oriented tools like dictionaries, OCR,
translation, text analysis software, etc.</p>
<p>Examples: kdrill, stardict, turkey</p>
</item>
- <tag>TV and Radio</tag>
+ <tag>Applications/TV and Radio</tag>
<item>
<p>TV-in, TV-out, FM radio, teletext browsers, etc.</p>
<p>Examples: gradio, gatos, alevt</p>
</item>
- <tag>Viewers</tag>
+ <tag>Applications/Viewers</tag>
<item>
<p>Software for viewing images, documents
and other (non-video) media.</p>
<p>Examples: gqview, evince, gthumb</p>
</item>
- <tag>Video</tag>
+ <tag>Applications/Video</tag>
<item>
<p>Video players, editors, and rippers/recorders.</p>
<p>Examples: istanbul, totem, kino</p>
</item>
- <tag>Web Development</tag>
+ <tag>Applications/Web Development</tag>
<item>
<p>Software for web site editing, web
programming, and site administration.</p>
<item>
Games and recreations
<taglist>
- <tag>Action</tag>
+ <tag>Games/Action</tag>
<item>
<p>Games that involve a lot of action
and require fast reflexes.</p>
<p>Examples: xsoldier, supertux, xmoto</p>
</item>
- <tag>Adventure</tag>
+ <tag>Games/Adventure</tag>
<item>
<p>Role playing and adventure games,
interactive movies and stories, etc.</p>
<p>Examples: beneath-a-steel-sky, egoboo, kq</p>
</item>
- <tag>Blocks</tag>
+ <tag>Games/Blocks</tag>
<item>
<p>Tetris-like games involving falling blocks.</p>
<p>Examples: crack-attack, frozen-bubble, netris</p>
</item>
- <tag>Board</tag>
+ <tag>Games/Board</tag>
<item>
<p>Games played on a board.</p>
<p>Examples: phalanx, xshogi, xboard</p>
</item>
- <tag>Card</tag>
+ <tag>Games/Card</tag>
<item>
<p>Games involving a deck of cards.</p>
<p>Examples: pysol, ace-of-penguins, xpat2</p>
</item>
- <tag>Puzzles</tag>
+ <tag>Games/Puzzles</tag>
<item>
<p>Tests of ingenuity and logic.</p>
<p>Examples: xmpuzzles, sgt-puzzles, enigma</p>
</item>
- <tag>Simulation</tag>
+ <tag>Games/Simulation</tag>
<item>
<p>Simulations of the real world
in all detail and complexity.</p>
<p>Examples: flightgear, torcs</p>
</item>
- <tag>Strategy</tag>
+ <tag>Games/Strategy</tag>
<item>
<p>Games involving long-term strategic thinking.</p>
<p>Examples: wesnoth, widelands, netpanzer</p>
</item>
- <tag>Tools</tag>
+ <tag>Games/Tools</tag>
<item>
<p>Server browsers, configurators, editors, and other
game-related tools that are not games themselves.</p>
<p>Examples: xqf, crystalspace</p>
</item>
- <tag>Toys</tag>
+ <tag>Games/Toys</tag>
<item>
<p>Amusements, eye-candy, entertaining
demos, screen hacks (screensavers), etc.</p>
<item>
Programs that affect the whole screen.
<taglist>
- <tag>Saving</tag>
+ <tag>Screen/Saving</tag>
<item>
<p>Tools for blanking the screen. Entries of screen hacks and
configuration GUIs should go to other appropriate sections.
</p>
<p>Examples: xscreensaver, xlockmore</p>
</item>
- <tag>Locking</tag>
+ <tag>Screen/Locking</tag>
<item>
<p>Tools for locking the screen.</p>
<p>Examples: xscreensaver, xlockmore</p>
+++ /dev/null
-<!doctype debiandoc public "-//DebianDoc//DTD DebianDoc//EN">
-<debiandoc>
- <book>
- <titlepag>
- <title>A mechanism for updating Debian Policy documents</title>
- <author>
- <name>Manoj Srivastava</name>
- <email>srivasta@debian.org</email>
- </author>
- <version>$Revision: 1.7 $</version>
- <copyright>
- <copyrightsummary>Copyright © 2000 by Manoj Srivastava.
- </copyrightsummary>
- <p>
- You are given permission to redistribute this document
- and/or modify it under the terms of the GNU General Public
- License as published by the Free Software Foundation; either
- version 2, or (at your option) any later version.</p>
- <p>
- On Debian GNU/Linux systems, the complete text of the GNU
- General Public License can be found in
- <tt>/usr/share/common-licenses/GPL</tt>. </p>
- </copyright>
- </titlepag>
- <toc detail="sect">
- <chapt>
- <heading>Introduction, and Administrivia</heading>
- <p>
- This document documents the current practice followed in updating
- Debian Policy documents. This mechanism has been designed for
- dealing with policy changes that are light
- weight and can be decided upon within the policy group, by
- near consensus. In most day-to-day cases, the Policy group
- should and must be able to conduct Policy discussions and
- amendments without the intervention of the Technical Committee
- or other Constitutional issues. Only in cases of extreme
- dispute (formal objections) should the intervention of
- Constitutional bodies come into play. In any other situation,
- the Policy group should be able to conduct business
- unfettered. A consequence of this goal is that formal
- objections should not be used lightly, else this mechanism
- shall be ineffective.
- </p>
- <p>
- It should be noted that the team responsible for the task of
- updating policy does not act as author or editor of Policy
- itself, that is the task of the Debian Policy mailing list.
- </p>
- <p>
- <em>In the following, the term developer refers to registered
- Debian developers.</em>
- </p>
- <sect>
- <heading>Guidelines for policy change proposals</heading>
- <p>
- Policy does not document all existing practice. It only
- incorporates a minimal ruleset that is required for systems
- integration (usually selecting one branch from several
- equally viable technical options). It is not a best
- practices document.
- </p>
- <p>
- Policy changes under this procedure also should almost never
- (unless directed by the tech-ctte, and perhaps the DPL)
- cause a change that would make a significant chunk of
- packages instantly buggy; for such changes, it is better to
- implement a gradual transition plan, allowing for partial
- upgrades (and perhaps using release goals as
- motivators). Part of the rationale for this is common sense;
- a global change, in the past, has taken time, and having
- either a large number of RC bugs, or ignoring a large number
- of bugs that would otherwise be RC seems silly; and, anyway,
- there are concerns that the policy group does not really
- have the power to change policy drastically. This is the
- basis of the maxim <em>policy shall not be used as a stick to beat
- developers with.</em>
- </p>
-
- <p>
- Nor does policy <em>always</em> document only existing
- practices. What that oft misquoted statement refers to was
- a part of a larger thesis that is meant to suggest that
- policy is not the place for testing out design; if a
- complicated technical proposal is to be made into policy, it
- should be independently implemented, have all the kinks
- worked out, and then have that working model be implemented
- as policy. Having to change policy back and forth while a
- design is being worked out needs be avoided.
- </p>
-
- </sect>
-
- </chapt>
- <chapt>
- <heading>Archives and Personnel</heading>
- <sect>
- <heading>The policy maintainers team</heading>
- <p>
- The policy document is maintained by a group of people who have
- access to the CVS repository for the Policy documents;
- however, this set of people behave more like maintainers
- rather than authors/editors. This group does not create
- policy, nor does it exercise editorial control, Policy is
- decided "upstream". The group that decides on policy should
- be the group of developers on the debian-policy mailing
- list, which is how it was always done; so the group of
- policy maintainers have no real power over policy.
- </p>
- <p>
- Since the policy maintainers have no special powers, there
- is no restriction of their participation the discussion. It
- is preferable to have at least 4-5 people on the job,
- perhaps closer to 8, so that policy does not languish when
- any maintainer goes missing (we do need vacations, you know,
- once in a while), and since little creative power is vested
- in the maintainers, we do not need a central control. And
- the BTS can be used as a record of the action decided upon
- even if all maintainers are away at some time.
- </p>
- </sect>
- <sect>
- <heading>The CVS Repository</heading>
- <p>
- There is a repository set up on <tt>cvs.debian.org</tt> for
- this, and the people on the policy maintainer team have
- write access to it. The Debian policy mailing list gets
- copies of all the CVS commit notices.
- </p>
- </sect>
- </chapt>
- <chapt>
- <heading>Procedures and Processes</heading>
-
- <sect>
- <heading>Initiating discussions</heading>
- <p>
- Unlike before, when the policy editor gathered in issues
- which, in his view, were candidates for inclusion in policy,
- any one can raise an issue in the mailing list. It is
- advisable, but by no means mandatory, that the proposer
- tries an idea out on the mailing list, which can help flesh
- out details rapidly, and test the sentiment and the
- collective wisdom of the list. Discussion may be initiated by
- any member of the list.
- </p>
- <p>
- Once the proposer is satisfied that the proposal has merit
- (with or without trying the waters on the list), the
- proposer should file a <em>wishlist</em> bug against the
- debian-policy package. This stage can be initiated by any
- member of the list.
- </p>
- </sect>
- <sect>
- <heading>Creating a proposal</heading>
-
- <p>
- Any Debian developer can create a proposal by retitling the
- wishlist bug in the BTS to have the subject of the form
- <strong>"[PROPOSED] ..."</strong> or
- <strong>"[PROPOSAL] ..."</strong>. (Note: The developer may
- coalesce these steps into one by directly filing a
- <em>wishlist</em> bug with the proper subject format).
- </p>
- <p>
- This is the pre-discussion period, when the idea is kicked
- around, and polished. There is no preset time limit, but at
- some point, if it is stalled, the bug should be closed. A
- suggested time period is 6 months, since if the
- proposal has had no action in that period, it is very likely
- dead. If six months have actually passed, the bug should be
- retitled <strong>"[OLD PROPOSAL] ..."</strong>, and have the
- severity set to fixed. The maintainers shall flush out old
- proposals after a sufficiently long period of time has
- elapsed (certainly more than a year or so after the initial
- proposal).
- </p>
- <p>
- Developers may second the issue by emailing a message
- containing the text "seconded" to the proposal in the
- BTS. Only registered Debian developers may second proposals.
- </p>
- </sect>
- <sect>
- <heading>Creating an Amendment</heading>
- <p>
- When a proposal in the BTS has acquired two seconds (apart
- from the proposer), it becomes a formal amendment. The bug
- severity is raised to "normal" and the bug is retitled to
- <strong>"[AMENDMENT DD/MM/YYYY] ..."</strong>.
- </p>
- <p>
- The rationale behind the requirement for seconders is that
- it would<enumlist>
- <item>
- <p>
- Encourage people to test the waters on the policy
- mailing list, and this could help create an proposal
- with a better chance of success</p>
- </item>
- <item>
- <p>
- Prevent frivolous or ill conceived proposals from
- wasting people's time (if the proposal does not even
- convince two developers, surely this is not ready for
- inclusion in Policy?)</p>
- </item>
- </enumlist>
- </p>
- <p>
- The whole discussion process is meant to be lightweight; if
- you wish the proposals to be amended, talk to the proposer,
- and get the amendment in. Or else, post an alternative, and
- let the group decide which one is better.
- </p>
- <p>
- If the process gets very contentious, and needs something
- like votes on amendments and withdrawal of proposal, then
- this is not the correct forum for this, and the procedures
- outlined in the constitution should be followed. Note that
- only non-technical issues can be resolved using the general
- resolution protocol; technical issues would hopefully be
- resolved in the group itself, or the technical committee can
- be called upon to render a decision.
- </p>
- <p>
- This document is not supposed to supplant the processes
- outlined in the constitution, nor is it intended to run
- around them.
- </p>
- </sect>
-
- <sect>
- <heading>Final disposition of the proposal</heading>
- <sect1>
- <heading>An accepted amendment</heading>
- <p>
- If the amendment is accepted, the bug is marked
- forwarded and retitled
- <strong>"[ACCEPTED DD/MM/YYYY] ..."</strong>.
- </p>
- </sect1>
- <sect1>
- <heading>An amendment that stalls or is rejected</heading>
- <p>
- If the amendment is stalls, or otherwise fails to pass, it
- is retitled as <strong>"[REJECTED DD/MM/YYYY] ..."</strong>
- and has its severity set to <tt>fixed</tt>.
- </p>
- </sect1>
- </sect>
-
-
- <sect>
- <heading>Deadlines for Tabling Discussions</heading>
- <p>
- It has been observed in the past that discussions on the
- mailing list tend to devolve into endless arguments. In
- order to get away from the debating society aspect, at the
- time of the formal proposal, a deadline can be set (probably
- by the proposer, since they are likely to have an idea how
- contentious the discussion is likely to be) for ending
- discussion on the issue, which should rarely be less than 10
- days, and typically two weeks or so. I hope that a hard
- minimum period need not be set, and that the proposers would
- be reasonable, and not set too short or too long a time for
- discussion.
- </p>
- <p>
- If a consensus is reached by the policy group, then the
- maintainers shall enter the amendment into the Policy
- document, announce the inclusion in the periodic report, and
- release a new version.</p>
- <sect1>
- <heading>Extensions to Deadlines?</heading>
- <p>
- If a deadline is approaching, and the discussion is almost
- concluded (in other words, it has not reached an impasse),
- and the consensus on the policy group is that an extension
- of a week would resolve the issues better, a one-time
- extension could be granted. Care should be taken in
- exercising this option, since abusing this would merely
- postpone closures. Anything that is still not resolved is
- too contentious not to be sent to the full set of
- developers in a general resolution proposal.
- </p>
- </sect1>
- </sect>
- <sect>
- <heading>Deadlock resolution</heading>
- <p>
- Formerly, arriving at a consensus was the only way to amend
- Policy. That worked well when the Project was small,
- however, we have apparently grown out of that phase, and even
- the policy mailing list has grown more fractious than in the
- days of yore. We now need a formal process of deadlock
- resolution, and we need to recognize that on non-technical
- issues a small minority should not always hold up deployment
- of policy.</p>
- <p>
- If a consensus is not reached, (or if someone submits a
- formal objection to the proposal) and the end of the
- discussion period is near, then one is faced with a dilemma.
- </p>
- <sect1>
- <heading>Impasse on Technical Issues</heading>
- <p>
- On technical issues, popularity is a bad way of arriving
- at conclusions. Hopefully, the policy group would arrive
- at a consensus on their own. If that fails to happen, or
- if there is a formal objection raised on the issue, and
- the issue is a technical one, then the technical committee
- may be consulted. This should be a rare occurrence. </p>
- </sect1>
- <sect1>
- <heading>Non Technical and Subjective Disagreements</heading>
- <p>
- However, if the issue is non-technical and subjective,
- then a vote of the developers may be taken (USENET voting
- software should be available all over the place, right?),
- and a super-majority of 75% is needed to carry the
- amendment through. Failing the super-majority, the issue
- should be shelved. It may be re-submitted as a a fresh
- proposal after a suitable cooling off period (which should
- be no less than a month, typically three months being
- desirable, unless there are significant new
- developments). (Demote bug, if the BTS is being used)</p>
- <p>
- If the issue raised is especially contentious, or is
- deemed to be suitable for review by the full set of
- developers, then four or more developers can call for a
- hold on the proposal, and move to send the proposal to the
- larger developer body as a General
- Resolution. <strong>Note:</strong> The constitution may
- have additional requirements for submitting a General
- Resolution, for example, a minimum number of seconders,
- etc.
- </p>
- </sect1>
- </sect>
- </chapt>
-
- </book>
-</debiandoc>
-<!-- Local variables: -->
-<!-- indent-tabs-mode: t -->
-<!-- End: -->
</p>
</sect>
+ <sect id="definitions">
+ <heading>Definitions</heading>
+
+ <p>
+ The following terms are used in this Policy Manual:
+ <taglist>
+ <tag>ASCII</tag>
+ <item>
+ The character encoding specified by ANSI X3.4-1986 and its
+ predecessor standards, referred to in MIME as US-ASCII, and
+ corresponding to an encoding in eight bits per character of
+ the first 128 <url id="http://www.unicode.org/"
+ name="Unicode"> characters, with the eighth bit always zero.
+ </item>
+ <tag>UTF-8</tag>
+ <item>
+ The transformation format (sometimes called encoding) of
+ <url id="http://www.unicode.org/" name="Unicode"> defined by
+ <url id="http://www.rfc-editor.org/rfc/rfc3629.txt"
+ name="RFC 3629">. UTF-8 has the useful property of having
+ ASCII as a subset, so any text encoded in ASCII is trivially
+ also valid UTF-8.
+ </item>
+ </taglist>
+ </p>
+ </sect>
</chapt>
system, but not every package we want to make accessible is
<em>free</em> in our sense (see the Debian Free Software
Guidelines, below), or may be imported/exported without
- restrictions. Thus, the archive is split into the distribution
- areas or categories based on their licenses and other restrictions.
+ restrictions. Thus, the archive is split into areas<footnote>
+ The Debian archive software uses the term "component" internally
+ and in the Release file format to refer to the division of an
+ archive. The Debian Social Contract simply refers to "areas."
+ This document uses terminology similar to the Social Contract.
+ </footnote> based on their licenses and other restrictions.
</p>
<p>
</p>
<p>
- The <em>main</em> category forms the
- <em>Debian GNU/Linux distribution</em>.
+ The <em>main</em> archive area forms the <em>Debian GNU/Linux
+ distribution</em>.
</p>
<p>
- Packages in the other distribution areas (<tt>contrib</tt>,
+ Packages in the other archive areas (<tt>contrib</tt>,
<tt>non-free</tt>) are not considered to be part of the Debian
distribution, although we support their use and provide
infrastructure for them (such as our bug-tracking system and
</sect>
<sect id="sections">
- <heading>Categories</heading>
+ <heading>Archive areas</heading>
<sect1 id="main">
- <heading>The main category</heading>
+ <heading>The main archive area</heading>
<p>
Every package in <em>main</em> must comply with the DFSG
</sect1>
<sect1 id="contrib">
- <heading>The contrib category</heading>
+ <heading>The contrib archive area</heading>
<p>
Every package in <em>contrib</em> must comply with the DFSG.
</sect1>
<sect1 id="non-free">
- <heading>The non-free category</heading>
+ <heading>The non-free archive area</heading>
<p>
Packages must be placed in <em>non-free</em> if they are
<heading>Sections</heading>
<p>
- The packages in the categories <em>main</em>,
- <em>contrib</em> and <em>non-free</em> are grouped further
- into <em>sections</em> to simplify handling.
+ The packages in the archive areas <em>main</em>,
+ <em>contrib</em> and <em>non-free</em> are grouped further into
+ <em>sections</em> to simplify handling.
</p>
<p>
- The category and section for each package should be
- specified in the package's <tt>Section</tt> control record
- (see <ref id="f-Section">). However, the maintainer of the
- Debian archive may override this selection to ensure the
- consistency of the Debian distribution. The
- <tt>Section</tt> field should be of the form:
+ The archive area and section for each package should be
+ specified in the package's <tt>Section</tt> control record (see
+ <ref id="f-Section">). However, the maintainer of the Debian
+ archive may override this selection to ensure the consistency of
+ the Debian distribution. The <tt>Section</tt> field should be
+ of the form:
<list compact="compact">
<item>
<em>section</em> if the package is in the
- <em>main</em> category,
+ <em>main</em> archive area,
</item>
<item>
- <em>segment/section</em> if the package is in
+ <em>area/section</em> if the package is in
the <em>contrib</em> or <em>non-free</em>
- distribution areas.
+ archive areas.
</item>
</list>
</p>
with required, important, standard or optional
priorities, or are only likely to be useful if you
already know what they are or have specialized
- requirements.
+ requirements (such as packages containing only detached
+ debugging symbols).
</item>
</taglist>
</p>
(see below), and should not do so unless they depend on a
particular version of that package.<footnote>
<p>
- Essential is defined as the minimal set of functionality
- that must be available and usable on the system even
- when packages are in an unconfigured (but unpacked)
- state. This is needed to avoid unresolvable dependency
- loops on upgrade. If packages add unnecessary
- dependencies on packages in this set, the chances that
- there <strong>will</strong> be an unresolvable
- dependency loop caused by forcing these Essential
- packages to be configured first before they need to be
- is greatly increased. It also increases the chances
- that frontends will be unable to
- <strong>calculate</strong> an upgrade path, even if one
- exists.
+ Essential is needed in part to avoid unresolvable dependency
+ loops on upgrade. If packages add unnecessary dependencies
+ on packages in this set, the chances that there
+ <strong>will</strong> be an unresolvable dependency loop
+ caused by forcing these Essential packages to be configured
+ first before they need to be is greatly increased. It also
+ increases the chances that frontends will be unable to
+ <strong>calculate</strong> an upgrade path, even if one
+ exists.
</p>
<p>
- Also, it's pretty unlikely that functionality from
- Essential shall ever be removed (which is one reason why
- care must be taken before adding to the Essential
- packages set), but <em>packages</em> have been removed
- from the Essential set when the functionality moved to a
- different package. So depending on these packages
- <em>just in case</em> they stop being essential does way
- more harm than good.
+ Also, functionality is rarely ever removed from the
+ Essential set, but <em>packages</em> have been removed from
+ the Essential set when the functionality moved to a
+ different package. So depending on these packages <em>just
+ in case</em> they stop being essential does way more harm
+ than good.
</p>
</footnote>
</p>
<heading>Essential packages</heading>
<p>
- Some packages are tagged <tt>essential</tt> for a system
- using the <tt>Essential</tt> control file field.
- The format of the <tt>Essential</tt> control field is
- described in <ref id="f-Essential">.
+ Essential is defined as the minimal set of functionality that
+ must be available and usable on the system at all times, even
+ when packages are in an unconfigured (but unpacked) state.
+ Packages are tagged <tt>essential</tt> for a system using the
+ <tt>Essential</tt> control file field. The format of the
+ <tt>Essential</tt> control field is described in <ref
+ id="f-Essential">.
</p>
<p>
appropriate.
</p>
+ <p>
+ Maintainers should take great care in adding any programs,
+ interfaces, or functionality to <tt>essential</tt> packages.
+ Packages may assume that functionality provided by
+ <tt>essential</tt> packages is always available without
+ declaring explicit dependencies, which means that removing
+ functionality from the Essential set is very difficult and is
+ almost never done. Any capability added to an
+ <tt>essential</tt> package therefore creates an obligation to
+ support that capability as part of the Essential set in
+ perpetuity.
+ </p>
+
<p>
You must not tag any packages <tt>essential</tt> before
this has been discussed on the <tt>debian-devel</tt>
Package maintainer scripts may prompt the user if
necessary. Prompting should be done by communicating
through a program, such as <prgn>debconf</prgn>, which
- conforms to the Debian Configuration management
- specification, version 2 or higher. Prompting the user by
+ conforms to the Debian Configuration Management
+ Specification, version 2 or higher. Prompting the user by
other means, such as by hand<footnote>
From the Jargon file: by hand 2. By extension,
writing code which does something in an explicit or
</p>
<p>
- The Debian Configuration management specification is included
+ The Debian Configuration Management Specification is included
in the <file>debconf_specification</file> files in the
<package>debian-policy</package> package.
It is also available from the Debian web mirrors at
</p>
<p>
- Packages which use the Debian Configuration management
- specification may contain an additional
+ Packages which use the Debian Configuration Management
+ Specification may contain an additional
<prgn>config</prgn> script and a <tt>templates</tt>
file in their control archive<footnote>
The control.tar.gz inside the .deb.
Therefore it must work using only the tools present in
<em>essential</em> packages.<footnote>
<package>Debconf</package> or another tool that
- implements the Debian Configuration management
- specification will also be installed, and any
+ implements the Debian Configuration Management
+ Specification will also be installed, and any
versioned dependencies on it will be satisfied
before preconfiguration begins.
</footnote>
</p>
<p>
- Packages which use the Debian Configuration management
- specification must allow for translation of their messages
- by using a gettext-based system such as the one provided by
- the <package>po-debconf</package> package.
+ Packages which use the Debian Configuration Management
+ Specification must allow for translation of their user-visible
+ messages by using a gettext-based system such as the one
+
provided by the <package>po-debconf</package> package.
</p>
<p>
</footnote>
</p>
- <p>
-
- </p>
-
<p>
The format of the <file>debian/changelog</file> allows the
package building tools to discover which version of the package
/closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i
</example>
Then all of the bug numbers listed will be closed by the
- archive maintenance script (<prgn>katie</prgn>), or in
- the case of an NMU, marked as fixed.
+ archive maintenance script (<prgn>katie</prgn>) using the
+ <var>version</var> of the changelog entry.
</footnote>
This information is conveyed via the <tt>Closes</tt> field
in the <tt>.changes</tt> file (see <ref id="f-Closes">).
</p>
<p>
- The <var>date</var> should be in RFC822 format<footnote>
+ The <var>date</var> must be in RFC822 format<footnote>
This is generated by <tt>date -R</tt>.
- </footnote>; it should include the time zone specified
+ </footnote>; it must include the time zone specified
numerically, with the time zone name or abbreviation
optionally present as a comment in parentheses.
</p>
<p>
- The first "title" line with the package name should start
- at the left hand margin; the "trailer" line with the
- maintainer and date details should be preceded by exactly
+ The first "title" line with the package name must start
+ at the left hand margin. The "trailer" line with the
+ maintainer and date details must be preceded by exactly
one space. The maintainer details and the date must be
separated by exactly two spaces.
</p>
+ <p>
+ The entire changelog must be encoded in UTF-8.
+ </p>
+
<p>
For more information on placement of the changelog files
within binary packages, please see <ref id="changelogs">.
</p>
-
- <sect1><heading>Alternative changelog formats</heading>
-
- <p>
- In non-experimental packages you must use a format for
- <file>debian/changelog</file> which is supported by the most
- recent released version of <prgn>dpkg</prgn>.
- </p>
-
- <p>
- It is possible to use a format different from the standard
- one by providing a changelog parser for the format you wish
- to use. The parser must have an API compatible with that
- expected by <prgn>dpkg-genchanges</prgn> and
- <prgn>dpkg-gencontrol</prgn>, and it must not interact with
- the user at all.
- <footnote>
- If there is general interest in the new format, you should
- contact the <package>dpkg</package> maintainer to have the
- parser script for it included in the <prgn>dpkg</prgn>
- package. (You will need to agree that the parser and its
- man page may be distributed under the GNU GPL, just as the rest
- of <prgn>dpkg</prgn> is.)
- </footnote>
- </p>
- </sect1>
</sect>
+
<sect id="dpkgcopyright">
<heading>Copyright: <file>debian/copyright</file></heading>
<p>
<p>
The meaning of the following tags has been standardized:
<taglist>
+ <tag>nocheck</tag>
+ <item>
+ This tag says to not run any build-time test suite
+ provided by the package.
+ </item>
<tag>noopt</tag>
<item>
The presence of this tag means that the package should
NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
MAKEFLAGS += -j$(NUMJOBS)
endif
+
+build:
+ # ...
+ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
+ # Code to run the package test suite.
+endif
</example>
</p>
</sect1>
</p>
<p>
- See <manref name="dpkg-source" section="1"> for full
+ See <manref name="deb-substvars" section="5"> for full
details about source variable substitutions, including the
format of <file>debian/substvars</file>.</p>
</sect>
If running <prgn>dpkg-source -x</prgn> on a source package
doesn't produce the source of the package, ready for editing,
and allow one to make changes and run
- <prng>dpkg-buildpackage</prgn> to produce a modified package
+ <prgn>dpkg-buildpackage</prgn> to produce a modified package
without taking any additional steps, creating a
<file>debian/README.source</file> documentation file is
recommended. This file should explain how to do all of the
would mean a new paragraph.
</p>
+ <p>
+ All control files must be encoded in UTF-8.
+ </p>
</sect>
<sect id="sourcecontrolfiles">
See <ref id="substvars"> for details.
</p>
+ <p>
+ In addition to the control file syntax described <qref
+ id="controlsyntax">above</qref>, this file may also contain
+ comment lines starting with <tt>#</tt> without any preceding
+ whitespace. All such lines are ignored, even in the middle of
+ continuation lines for a multiline field, and do not end a
+ multiline field.
+ </p>
+
</sect>
<sect id="binarycontrolfiles">
number apart at the last hyphen in the string (if there
is one) to determine the <var>upstream_version</var> and
<var>debian_revision</var>. The absence of a
- <var>debian_revision</var> compares earlier than the
- presence of one (but note that the
- <var>debian_revision</var> is the least significant part
- of the version number).
+ <var>debian_revision</var> is equivalent to a
+ <var>debian_revision</var> of <tt>0</tt>.
</p>
</item>
</taglist>
</p>
<p>
- The <var>upstream_version</var> and <var>debian_revision</var>
+ When comparing two version numbers, first the <var>epoch</var>
+ of each are compared, then the <var>upstream_version</var> if
+ <var>epoch</var> is equal, and then <var>debian_revision</var>
+ if <var>upstream_version</var> is also equal.
+ <var>epoch</var> is compared numerically. The
+ <var>upstream_version</var> and <var>debian_revision</var>
parts are compared by the package management system using the
- same algorithm:
+ following algorithm:
</p>
<p>
scripts this means that you <em>almost always</em> need to
use <tt>set -e</tt> (this is usually true when writing shell
scripts, in fact). It is also important, of course, that
- they don't exit with a non-zero status if everything went
- well.
+ they exit with a zero status if everything went well.
</p>
<p>
Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
hurd-dev [hurd-i386], gnumach-dev [hurd-i386]
</example>
+ requires <tt>kernel-headers-2.2.10</tt> on all architectures
+ other than hurd-i386 and requires <tt>hurd-dev</tt> and
+ <tt>gnumach-dev</tt> only on hurd-i386.
+ </p>
+
+ <p>
+ If the architecture-restricted dependency is part of a set of
+ alternatives using <tt>|</tt>, that alternative is ignored
+ completely on architectures that do not match the restriction.
+ For example:
+ <example compact="compact">
+Build-Depends: foo [!i386] | bar [!amd64]
+ </example>
+ is equivalent to <tt>bar</tt> on the i386 architecture, to
+ <tt>foo</tt> on the amd64 architecture, and to <tt>foo |
+ bar</tt> on all other architectures.
</p>
<p>
instead.
</p>
- <p>
- If your package includes run-time support programs that
- do not need to be invoked manually by users, but are
- nevertheless required for the package to function, then it
- is recommended that these programs are placed
- (if they are binary) in a subdirectory of
- <file>/usr/lib</file>, preferably under
- <file>/usr/lib/</file><var>package-name</var>.
- If the program is architecture independent, the
- recommendation is for it to be placed in a subdirectory of
- <file>/usr/share</file> instead, preferably under
- <file>/usr/share/</file><var>package-name</var>.
- </p>
-
-
<p>
If you have several shared libraries built from the same
source tree you may lump them all together into a single
</sect>
- <sect id="sharedlibs-runtime-progs">
- <heading>Run-time support programs</heading>
+ <sect id="sharedlibs-support-files">
+ <heading>Shared library support files</heading>
- <p>
- If your package has some run-time support programs which use
- the shared library you must not put them in the shared
- library package. If you do that then you won't be able to
- install several versions of the shared library without
- getting filename clashes.
- </p>
+ <p>
+ If your package contains files whose names do not change with
+ each change in the library shared object version, you must not
+ put them in the shared library package. Otherwise, several
+ versions of the shared library cannot be installed at the same
+ time without filename clashes, making upgrades and transitions
+ unnecessarily difficult.
+ </p>
- <p>
- Instead, either create another package for the runtime binaries
- (this package might typically be named
- <package><var>libraryname</var>-runtime</package>; note the absence
- of the <var>soversion</var> in the package name), or if the
- development package is small, include them in there.
- </p>
+ <p>
+ It is recommended that supporting files and run-time support
+ programs that do not need to be invoked manually by users, but
+ are nevertheless required for the package to function, be placed
+ (if they are binary) in a subdirectory of <file>/usr/lib</file>,
+ preferably under <file>/usr/lib/</file><var>package-name</var>.
+ If the program or file is architecture independent, the
+ recommendation is for it to be placed in a subdirectory of
+ <file>/usr/share</file> instead, preferably under
+ <file>/usr/share/</file><var>package-name</var>. Following the
+ <var>package-name</var> naming convention ensures that the file
+ names change when the shared object version changes.
+ </p>
+
+ <p>
+ Run-time support programs that use the shared library but are
+ not required for the library to function or files used by the
+ shared library that can be used by any version of the shared
+ library package should instead be put in a separate package.
+ This package might typically be named
+ <package><var>libraryname</var>-tools</package>; note the
+ absence of the <var>soversion</var> in the package name.
+ </p>
+
+ <p>
+ Files and support programs only useful when compiling software
+ against the library should be included in the development
+ package for the library.<footnote>
+ For example, a <file><var>package-name</var>-config</file>
+ script or <package>pkg-config</package> configuration files.
+ </footnote>
+ </p>
</sect>
<sect id="sharedlibs-static">
The <file>/usr/local</file> directory itself and all the
subdirectories created by the package should (by default) have
permissions 2775 (group-writable and set-group-id) and be
- owned by <tt>root.staff</tt>.
+ owned by <tt>root:staff</tt>.
</p>
</sect1>
<tt>K</tt> prefix, but they too are called with the single
argument <tt>stop</tt>.
</p>
-
- <p>
- Also, if the script name ends in <tt>.sh</tt>, the script
- will be sourced in runlevel <tt>S</tt> rather than being
- run in a forked subprocess, but will be explicitly run by
- <prgn>sh</prgn> in all other runlevels.
- </p>
</sect1>
<sect1>
<p>
The <file>init.d</file> scripts must ensure that they will
- behave sensibly if invoked with <tt>start</tt> when the
- service is already running, or with <tt>stop</tt> when it
- isn't, and that they don't kill unfortunately-named user
- processes. The best way to achieve this is usually to use
- <prgn>start-stop-daemon</prgn>.
+ behave sensibly (i.e., returning success and not starting
+ multiple copies of a service) if invoked with <tt>start</tt>
+ when the service is already running, or with <tt>stop</tt>
+ when it isn't, and that they don't kill unfortunately-named
+ user processes. The best way to achieve this is usually to
+ use <prgn>start-stop-daemon</prgn> with the <tt>--oknodo</tt>
+ option.
</p>
<p>
script must behave sensibly and not fail if the
<file>/etc/default</file> file is deleted.
</p>
+
+ <p>
+ <file>/var/run</file> and <file>/var/lock</file> may be mounted
+ as temporary filesystems<footnote>
+ For example, using the <tt>RAMRUN</tt> and <tt>RAMLOCK</tt>
+ options in <file>/etc/default/rcS</file>.
+ </footnote>, so the <file>init.d</file> scripts must handle this
+ correctly. This will typically amount to creating any required
+ subdirectories dynamically when the <file>init.d</file> script
+ is run, rather than including them in the package and relying on
+ <prgn>dpkg</prgn> to create them.
+ </p>
</sect1>
<sect1>
support <tt>-a</tt> and <tt>-o</tt> as binary logical
operators.</item>
<item><tt>local</tt> to create a scoped variable must be
- supported; however, <tt>local</tt> may or may not preserve
- the variable value from an outer scope and may or may not
- support arguments more complex than simple variables. Only
- uses such as:
+ supported, including listing multiple variables in a single
+ local command and assigning a value to a variable at the
+ same time as localizing it. <tt>local</tt> may or
+ may not preserve the variable value from an outer scope if
+ no assignment is present. Uses such as:
<example compact>
fname () {
- local a
- a=''
- # ... use a ...
+ local a b c=delta d
+ # ... use a, b, c, d ...
}
</example>
- must be supported.
+ must be supported and must set the value of <tt>c</tt> to
+ <tt>delta</tt>.
</item>
</list>
If a shell script requires non-SUSv3 features from the shell
</p>
<p>
- Files should be owned by <tt>root.root</tt>, and made
+ Files should be owned by <tt>root:root</tt>, and made
writable only by the owner and universally readable (and
executable, if appropriate), that is mode 644 or 755.
</p>
</p>
<p>
- Mailboxes are generally mode 660
- <tt><var>user</var>.mail</tt> unless the system
- administrator has chosen otherwise. A MUA may remove a
- mailbox (unless it has nonstandard permissions) in which
- case the MTA or another MUA must recreate it if needed.
- Mailboxes must be writable by group mail.
- </p>
-
- <p>
- The mail spool is 2775 <tt>root.mail</tt>, and MUAs should
+ Mailboxes are generally either mode 600 and owned by
+ <var>user</var> or mode 660 and owned by
+ <tt><var>user</var>:mail</tt><footnote>
+ There are two traditional permission schemes for mail spools:
+ mode 600 with all mail delivery done by processes running as
+ the destination user, or mode 660 and owned by group mail with
+ mail delivery done by a process running as a system user in
+ group mail. Historically, Debian required mode 660 mail
+ spools to enable the latter model, but that model has become
+ increasingly uncommon and the principle of least privilege
+ indicates that mail systems that use the first model should
+ use permissions of 600. If delivery to programs is permitted,
+ it's easier to keep the mail system secure if the delivery
+ agent runs as the destination user. Debian Policy therefore
+ permits either scheme.
+ </footnote>. The local system administrator may choose a
+ different permission scheme; packages should not make
+ assumptions about the permission and ownership of mailboxes
+ unless required (such as when creating a new mailbox). A MUA
+ may remove a mailbox (unless it has nonstandard permissions) in
+ which case the MTA or another MUA must recreate it if needed.
+ </p>
+
+ <p>
+ The mail spool is 2775 <tt>root:mail</tt>, and MUAs should
be setgid mail to do the locking mentioned above (and
must obviously avoid accessing other users' mailboxes
using this privilege).</p>
in the <em>X Toolkit Intrinsics - C Language
Interface</em> manual is also permitted). They must be
registered as <tt>conffile</tt>s or handled as
- configuration files. Packages must not provide the
- directory <file>/usr/X11R6/lib/X11/app-defaults/</file>.
+ configuration files.
</p>
<p>
are stored in the X server and affect all connecting
clients.
</footnote>
- <em>Important:</em> packages that install files into the
- <file>/etc/X11/Xresources/</file> directory must conflict with
- <tt>xbase (<< 3.3.2.3a-2)</tt>; if this is not done
- it is possible for the installing package to destroy a
- previously-existing <file>/etc/X11/Xresources</file> file
- which had been customized by the system administrator.
</p>
</sect1>
Games which require protected, privileged access to
high-score files, saved games, etc., may be made
set-<em>group</em>-id (mode 2755) and owned by
- <tt>root.games</tt>, and use files and directories with
- appropriate permissions (770 <tt>root.games</tt>, for
+ <tt>root:games</tt>, and use files and directories with
+ appropriate permissions (770 <tt>root:games</tt>, for
example). They must not be made
set-<em>user</em>-id, as this causes security problems. (If
an attacker can subvert any set-user-id game they can
</p>
<p>
- Packages in the <em>contrib</em> or <em>non-free</em> categories
- should state in the copyright file that the package is not part
- of the Debian GNU/Linux distribution and briefly explain why.
+ Packages in the <em>contrib</em> or <em>non-free</em> archive
+ areas should state in the copyright file that the package is not
+ part of the Debian GNU/Linux distribution and briefly explain
+ why.
</p>
<p>
</example>
To view the copyright file for a package you could use this command:
<example>
- dpkg --fsys-tarfile <var>filename</var>.deb | tar xOf - \*/copyright | pager
+ dpkg --fsys-tarfile <var>filename</var>.deb | tar xOf - --wildcards \*/copyright | pager
</example>
</p>
</sect>
</p>
<p>
- Its arguments are executables.
+ Its arguments are executables and shared libraries
<footnote>
- <p>
- In a forthcoming dpkg version,
- <prgn>dpkg-shlibdeps</prgn> would be required to be
- called on shared libraries as well.
- </p>
<p>
They may be specified either in the locations in the
source tree where they are created or in the locations
and then in its main control file <file>debian/control</file>:
<example>
<var>...</var>
- Depends: ${shlibs:Pre-Depends}
+ Depends: ${shlibs:Depends}
Recommends: ${shlibs:Recommends}
<var>...</var>
</example>
<p>
This program can be used manually, but is also invoked by
<tt>dpkg-buildpackage</tt> or <file>debian/rules</file> to set
- to set environment or make variables which specify the build and
- host architecture for the package building process.
+ environment or make variables which specify the build and host
+ architecture for the package building process.
</p>
</sect1>
</sect>
See <ref id="dpkgchangelog">.
</p>
- <p>
- It is recommended that the entire changelog be encoded in the
- <url id="http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2279.html" name="UTF-8">
- encoding of
- <url id="http://www.unicode.org/"
- name="Unicode">.<footnote>
- <p>
- I think it is fairly obvious that we need to
- eventually transition to UTF-8 for our package
- infrastructure; it is really the only sane char-set in
- an international environment. Now, we can't switch to
- using UTF-8 for package control fields and the like
- until dpkg has better support, but one thing we can
- start doing today is requesting that Debian changelogs
- are UTF-8 encoded. At some point in time, we can start
- requiring them to do so.
- </p>
- <p>
- Checking for non-UTF8 characters in a changelog is
- trivial. Dump the file through
- <example>iconv -f utf-8 -t ucs-4</example>
- discard the output, and check the return
- value. If there are any characters in the stream
- which are invalid UTF-8 sequences, iconv will exit
- with an error code; and this will be the case for the
- vast majority of other character sets.
- </p>
- </footnote>
- </p>
-
<sect2><heading>Defining alternative changelog formats
</heading>
supposing that a <prgn>smailwrapper</prgn> package wishes to
install a wrapper around <file>/usr/sbin/smail</file>:
<example>
- if [ install = "$1" ]; then
- dpkg-divert --package smailwrapper --add --rename \
- --divert /usr/sbin/smail.real /usr/sbin/smail
- fi
- </example> Testing <tt>$1</tt> is necessary so that the script
- doesn't try to add the diversion again when
- <prgn>smailwrapper</prgn> is upgraded. The <tt>--package
- smailwrapper</tt> ensures that <prgn>smailwrapper</prgn>'s
- copy of <file>/usr/sbin/smail</file> can bypass the diversion and
- get installed as the true version.
+ dpkg-divert --package smailwrapper --add --rename \
+ --divert /usr/sbin/smail.real /usr/sbin/smail
+ </example> The <tt>--package smailwrapper</tt> ensures that
+ <prgn>smailwrapper</prgn>'s copy of <file>/usr/sbin/smail</file>
+ can bypass the diversion and get installed as the true version.
+ It's safe to add the diversion unconditionally on upgrades since
+ it will be left unchanged if it already exists, but
+ <prgn>dpkg-divert</prgn> will display a message. To suppress that
+ message, make the command conditional on the version from which
+ the package is being upgraded:
+ <example>
+ if [ upgrade != "$1" ] || dpkg --compare-versions "$2" lt 1.0-2; then
+ dpkg-divert --package smailwrapper --add --rename \
+ --divert /usr/sbin/smail.real /usr/sbin/smail
+ fi
+ </example> where <tt>1.0-2</tt> is the version at which the
+ diversion was first added to the package. Running the command
+ during abort-upgrade is pointless but harmless.
</p>
<p>
The postrm has to do the reverse:
<example>
- if [ remove = "$1" ]; then
+ if [ remove = "$1" -o abort-install = "$1" -o disappear = "$1" ]; then
+ dpkg-divert --package smailwrapper --remove --rename \
+ --divert /usr/sbin/smail.real /usr/sbin/smail
+ fi
+ </example> If the diversion was added at a particular version, the
+ postrm should also handle the failure case of upgrading from an
+ older version (unless the older version is so old that direct
+ upgrades are no longer supported):
+ <example>
+ if [ abort-upgrade = "$1" ] && dpkg --compare-versions "$2" lt 1.0-2; then
dpkg-divert --package smailwrapper --remove --rename \
--divert /usr/sbin/smail.real /usr/sbin/smail
fi
- </example>
+ </example> where <tt>1.02-2</tt> is the version at which the
+ diversion was first added to the package. The postrm should not
+ remove the diversion on upgrades both because there's no reason to
+ remove the diversion only to immediately re-add it and since the
+ postrm of the old package is run after unpacking so the removal of
+ the diversion will fail.
</p>
<p>
<html>
<head>
<!-- -*- Mode: Sgml -*-
- upgrading-checklist.html
- Author : Manoj Srivastava ( srivasta@tiamat.datasync.com )
- Created On : Thu Oct 29 20:54:48 1998
- Created On Node : tiamat.datasync.com
- Last Modified By : Manoj Srivastava
- Last Modified On : Sat Jun 18 00:16:40 2005
- Last Machine Used: glaurung.internal.golden-gryphon.com
- Update Count : 51
- Status : Unknown, Use with caution!
- HISTORY :
- Description :
-
-->
<h2>The checklist</h2>
<pre>
-3.7.4.0 unreleased
+3.8.1.0 unreleased
+
+ * Care should be taken when adding functionality to essential and
+ such additions create an obligation to support that functionality
+ in essential forever unless significant work is done. [3.8]
+ * Changelog files must be encoded in UTF-8. [4.4]
+ * Tighten some format requirements for changelog files from a should
+ to a must. [4.4]
+ * Remove alternative changelog formats. Debian only supports one
+ changelog format for the Debian Archive. [4.4.1]
+ * New nocheck option for DEB_BUILD_OPTIONS indicating any build-time
+ test suite provided by the package should not be run. [4.9.1]
+ * All control files must be encoded in UTF-8. [5.1]
+ * debian/control allows comment lines starting with # with no
+ preceding whitespace. [5.2]
+ * Init scripts ending in .sh are not handled specially. They are not
+ sourced and are not guaranteed to be run by /bin/sh regardless of
+ the #! line. This brings Policy in line with the long-standing
+ behavior of the init system in Debian. [9.3]
+ * The start action of an init script must exit successfully and not
+ start the daemon again if it's already running. [9.3.2]
+ * /var/run and /var/lock may be mounted as temporary filesystems, and
+ init scripts must therefore create any necessary subdirectories
+ dynamically. [9.3.2]
+ * /bin/sh scripts may assume that local can take multiple variable
+ arguments and supports assignment. [10.4]
+ * User mailboxes may be mode 600 and owned by the user rather than
+ mode 660, owned by user, and group mail. [11.6]
+
+3.8.0.0 Jun 2008
* The base section has been removed. contrib and non-free have been
removed from the section list; they are only categories. The base
* Added parallel=n to the standardized DEB_BUILD_OPTIONS tags,
indicating that a package should be built using up to n parallel
processes if the package supports it [4.9.1]
- * Debian packages should not use convience copies of code from other
+ * Debian packages should not use convenience copies of code from other
packages unless the included package is explicitly intended to be
used that way. [4.13]
* If dpkg-source -x doesn't produce source ready for editing and
new upstream release and any other complexity of the Debian build
process. [4.14]
* The Uploaders field in debian/control may be wrapped. [5.6.3]
+ * An empty Debian revision is equivalent to a Debian revision of 0 in
+ a version number. [5.6.12]
* New Homepage field for upstream web sites. [5.6.23]
* The Breaks field declares that this package breaks another and
prevents installation of the breaking package unless the package
named in Breaks is deconfigured first. This field should not be
used until the dpkg in Debian stable supports it. [6.5, 6.6, 7]
+ * Clarify which files should go into a shared library package, into a
+ separate package, or into the -dev package. Suggest -tools instead
+ of -runtime for runtime support programs, since that naming is more
+ common in Debian. [8.1, 8.2]
* Files in /etc/cron.{hourly,daily,weekly,monthly} must be
configuration files (upgraded from should). Mention the hourly
directory. [9.5]
+ * Packages providing /etc/X11/Xresources files need not conflict with
+ xbase (<< 3.3.2.3a-2), which is long-obsolete. [11.8.6]
* Manual pages in locale-specific directories should use either the
legacy encoding for that directory or UTF-8. Country names should
not be included in locale-specific manual page directories unless
* Packages in contrib and non-free should state in the copyright file
that the package is not part of Debian GNU/Linux and briefly
explain why. [12.5]
+ * Underscore (_) is allowed in debconf template names. [debconf]
3.7.3.0 Dec 2007
projects / debian / debian-policy.git / commitdiff