/policy.html/
/stamp-build
/version.ent
+*-1.html
*.html.tar.gz
*.pdf
*.pdf.gz
menu-policy.sgml: version.ent
mime-policy.sgml: version.ent
+ifneq (,$(strip $(HAVE_ORG_EMACS)))
+%.txt: %.org
+ $(EMACS) --batch -Q -l ./README-css.el -l org -l org-ascii --visit $^ \
+ --funcall org-export-as-ascii >/dev/null 2>&1
+ test "$@" != "README.txt" || \
+ perl -pli -e 's,./Process.org,Process.txt,g' $@
+%.html: %.org
+ $(EMACS) --batch -Q -l ./README-css.el -l org --visit $^ \
+ --funcall org-export-as-html-batch >/dev/null 2>&1
+endif
+
%.validate: %
nsgmls -wall -gues $<
policy: html txt ps pdf
leavealone := $(FHS_HTML) $(FHS_FILES) $(FHS_ARCHIVE) \
- libc6-migration.txt \
- upgrading-checklist.html virtual-package-names-list.txt
+ libc6-migration.txt
.PHONY: distclean
distclean:
--- /dev/null
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml"
+lang="en" xml:lang="en">
+<head>
+<div style="text-align:right;font-size:70%;white-space:nowrap;">
+ <a accesskey="h" href="http://www.debian.org/"> UP </a>
+ |
+ <a accesskey="H" href="http://wiki.debian.org/Teams/Policy"> HOME </a>
+</div>
+
+<title>Debian Policy changes process</title>
+<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
+<meta name="generator" content="Org-mode"/>
+<meta name="generated" content="2009-09-13 16:13:52 CDT"/>
+<meta name="author" content="Margarita Manterola, Clint Adams, Russ Allbery, and Manoj Srivastava"/>
+<meta name="description" content=""/>
+<meta name="keywords" content=""/>
+
+<style type="text/css">
+ html { font-family: Times, serif; font-size: 12pt; }
+ .title { text-align: center; }
+ p.verse { margin-left: 3% }
+ pre {
+ border: 1pt solid #AEBDCC;
+ color: #000000;
+ background-color: LightSlateGray;
+ padding: 5pt;
+ font-family: "Courier New", courier, monospace;
+ font-size: 90%;
+ overflow:auto;
+ }
+ dt { font-weight: bold; }
+ div.figure { padding: 0.5em; }
+ div.figure p { text-align: center; }
+ .linenr { font-size:smaller }
+ .code-highlighted {background-color:#ffff00;}
+ .org-info-js_info-navigation { border-style:none; }
+ #org-info-js_console-label { font-size:10px; font-weight:bold;
+ white-space:nowrap; }
+ .org-info-js_search-highlight {background-color:#ffff00; color:#000000;
+ font-weight:bold; }
+
+ body {
+ color: DarkSlateGrey;
+ background-color: gainsboro;
+ font-family: Palatino, "Palatino Linotype", "Hoefler Text", "Times New Roman", Times, Georgia, Utopia, serif;
+ }
+ .org-agenda-date { color: #87cefa; }
+ .org-agenda-structure { color: #87cefa; }
+ .org-scheduled { color: #98fb98; }
+ .org-scheduled-previously { color: #ff7f24; }
+ .org-scheduled-today { color: #98fb98; }
+ .org-tag { font-weight: bold; }
+ .org-todo {
+ color: #ffc0cb;
+ font-weight: bold;
+ }
+
+ a {
+ color: inherit;
+ background-color: inherit;
+ font: inherit;
+ text-decoration: inherit;
+ }
+ a:hover { text-decoration: underline; }
+ .todo { font-weight:bold; }
+ .done { font-weight:bold; }
+ .TODO { color:red; }
+ .WAITING { color:orange; }
+ .DONE { color:green; }
+ .timestamp { color: grey }
+ .timestamp-kwd { color: CadetBlue }
+ .tag { background-color:lightblue; font-weight:normal }
+ .target { background-color: lavender; }
+table {
+ border-collapse: collapse; /*separate; */
+ border: outset 3pt;
+ border-spacing: 0pt;
+ /* border-spacing: 5pt; */
+ }
+table td { vertical-align: top; border: 1px solid; }
+table th { vertical-align: top; border: 2px solid; }
+</style>
+<script ="text/javascript" language="JavaScript" src="/styles/org-info.js"></script>
+<script type="text/javascript" language="JavaScript">
+/* <![CDATA[ */
+org_html_manager.set("LOCAL_TOC", 0);
+org_html_manager.set("VIEW_BUTTONS", 1);
+org_html_manager.set("VIEW", "info");
+org_html_manager.set("TOC", 1);
+org_html_manager.set("MOUSE_HINT", "underline"); // could be a background-color like #eeeeee
+org_html_manager.setup ();
+/* ]]> */
+</script>
+
+<script type="text/javascript">
+<!--/*--><![CDATA[/*><!--*/
+ function CodeHighlightOn(elem, id)
+ {
+ var target = document.getElementById(id);
+ if(null != target) {
+ elem.cacheClassElem = elem.className;
+ elem.cacheClassTarget = target.className;
+ target.className = "code-highlighted";
+ elem.className = "code-highlighted";
+ }
+ }
+ function CodeHighlightOff(elem, id)
+ {
+ var target = document.getElementById(id);
+ if(elem.cacheClassElem)
+ elem.className = elem.cacheClassElem;
+ if(elem.cacheClassTarget)
+ target.className = elem.cacheClassTarget;
+ }
+/*]]>*///-->
+</script>
+</head>
+<body>
+<div id="content">
+<h1 class="title">Debian Policy changes process</h1>
+
+
+<div id="outline-container-1" class="outline-2">
+<h2 id="sec-1">Change Goals </h2>
+<div class="outline-text-2" id="text-1">
+
+
+<ul>
+<li>
+The change should be technically correct, and consistent with the
+rest of the policy document. This means no legislating the value of
+π. This also means that the proposed solution be known to work;
+iterative design processes do not belong in policy.
+</li>
+<li>
+The change should not be too disruptive; if very many packages
+become instantly buggy, then instead there should be a transition
+plan. Exceptions should be rare (only if the current state is really
+untenable), and probably blessed by the TC.
+</li>
+<li>
+The change has to be reviewed in depth, in the open, where any one
+may contribute; a publicly accessible, archived, open mailing list.
+</li>
+<li>
+Proposal should be addressed in a timely fashion.
+</li>
+<li>
+Any domain experts should be consulted, since not every policy
+mailing list subscriber is an expert on everything, including policy
+maintainers.
+</li>
+<li>
+The goal is rough consensus on the change, which should not be hard
+if the matter is technical. Technical issues where there is no
+agreement should be referred to the TC; non-technical issues should
+be referred to the whole developer body, and perhaps general
+resolutions lie down that path.
+</li>
+<li>
+Package maintainers whose packages may be impacted should have
+access to policy change proposals, even if they do not subscribe to
+policy mailing lists (policy gazette?).
+
+</li>
+</ul>
+</div>
+
+</div>
+
+<div id="outline-container-2" class="outline-2">
+<h2 id="sec-2">Current Process </h2>
+<div class="outline-text-2" id="text-2">
+
+
+<p>
+Each suggested change goes through different states. These states are
+denoted through either usertags of the
+<a href="mailto:debian-policy@packages.debian.org">debian-policy@packages.debian.org</a> user or, for patch, pending, and
+wontfix, regular tags.
+</p>
+<p>
+<a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done">Current list of bugs</a>
+</p>
+<p>
+The Policy delegates are responsible for managing the tags on bugs and
+will update tags as new bugs are submitted or as activity happens on
+bugs. All Debian Developers should feel free to add the seconded tag
+as described below. Other tags should be changed with the coordination
+of the Policy Team.
+</p>
+
+</div>
+
+<div id="outline-container-2.1" class="outline-3">
+<h3 id="sec-2.1">State A: Issue raised </h3>
+<div class="outline-text-3" id="text-2.1">
+
+
+<p>
+Detect need, like gaps/flaws in current policy, or a new rule should
+be added. Any user or developer may start this step. There is a
+decision point here, not all issues are in scope of policy.
+<a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&tag=issue">TAG: issue</a>
+</p>
+<p>
+What needs to happen next: If this is in scope for Policy, discuss the
+issue and possible solutions, moving to the discussion tag, or if the
+matter is sufficiently clear, go directly to a proposal for how to
+address it, moving to the proposal tag. If this is not in scope for
+Policy, close the bug.
+</p>
+</div>
+
+</div>
+
+<div id="outline-container-2.2" class="outline-3">
+<h3 id="sec-2.2">State B: Discussion </h3>
+<div class="outline-text-3" id="text-2.2">
+
+
+<p>
+Discuss remedy. Alternate proposals. Discussion guided by
+delegates. There should be a clear time limit to this stage, but as
+yet we have not set one.
+<a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=discussion">TAG: discussion</a>
+</p>
+<p>
+What needs to happen next: Reach a conclusion and consensus in the
+discussion and make a final proposal for what should be changed (if
+anything), moving to the proposal tag.
+</p>
+</div>
+
+</div>
+
+<div id="outline-container-2.3" class="outline-3">
+<h3 id="sec-2.3">State D: Proposal </h3>
+<div class="outline-text-3" id="text-2.3">
+
+
+<p>
+A final proposal has emerged from the discussion, and there is a rough
+consensus on how to proceed to resolve the issue.
+<a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=proposal">TAG: proposal</a>
+</p>
+<p>
+What needs to happen next: Provided that the rough consensus persists,
+develop a patch against the current Policy document with specific
+wording of the change. Often this is done in conjunction with the
+proposal, in which case one may skip this step and move directly to
+patch tag.
+</p>
+</div>
+
+</div>
+
+<div id="outline-container-2.4" class="outline-3">
+<h3 id="sec-2.4">State E: Wording proposed </h3>
+<div class="outline-text-3" id="text-2.4">
+
+
+<p>
+A patch against the Policy document reflecting the consensus has been
+created and is waiting for formal seconds. The standard patch tag is
+used for this state, since it's essentially equivalent to the standard
+meaning of that tag.
+<a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=patch">TAG: patch</a>
+</p>
+<p>
+What needs to happen next: The proposal needs to be reviewed and
+seconded. Any Debian developer who agrees with the change and the
+conclusion of rough consensus from the discussion should say so in the
+bug log by seconding the proposal.
+</p>
+</div>
+
+</div>
+
+<div id="outline-container-2.5" class="outline-3">
+<h3 id="sec-2.5">State F: Seconded </h3>
+<div class="outline-text-3" id="text-2.5">
+
+
+<p>
+The proposal is signed off on by N Debian Developers. To start with,
+we're going with N=3, meaning that if three Debian Developers agree,
+not just with the proposal but with the conclusion that it reflects
+consensus and addresses the original issue – it is considered
+eligible for inclusion in the next version of Policy. Since Policy is
+partly a technical project governance method, one must be a Debian
+Developer to formally second, although review and discussion is
+welcome from anyone. Once this tag has been applied, the bug is
+waiting for a Policy team member to apply the patch to the package
+repository.
+<a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=seconded">TAG: seconded</a>
+</p>
+<p>
+What needs to happen next: A Policy maintainer does the final review
+and confirmation, and then applies the patch for the next Policy
+release.
+</p>
+<p>
+This tag is not used very much because normally a Policy maintainer
+applies the patch and moves the proposal to the next state once enough
+seconds are reached.
+</p>
+</div>
+
+</div>
+
+<div id="outline-container-2.6" class="outline-3">
+<h3 id="sec-2.6">State G: Accepted </h3>
+<div class="outline-text-3" id="text-2.6">
+
+
+<p>
+Change accepted, will be in next upload. The standard pending tag is
+used for this state since it matches the regular meaning of
+pending.
+<a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=pending">TAG: pending</a>
+</p>
+<p>
+What needs to happen next: The bug is now in the waiting queue for the
+next Policy release, and there's nothing left to do except for upload
+a new version of Policy.
+</p>
+</div>
+
+</div>
+
+<div id="outline-container-2.7" class="outline-3">
+<h3 id="sec-2.7">State H: Reject </h3>
+<div class="outline-text-3" id="text-2.7">
+
+
+<p>
+Rejected proposals. The standard wontfix is used for this
+state. Normally, bugs in this state will not remain open; instead, a
+Policy team member will close them with an explanation. The submitter
+may then appeal to the tech-ctte if they so desire. Alternately,
+issues appealed to the tech-ctte may remain open with this tag while
+that appeal proceeds.
+<a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=rejected">TAG: wontfix</a>
+</p>
+<p>
+We may use one of the following tags here, but to date we have only
+used dubious and ctte. It's not clear whether we need more tags for
+this tage.
+</p>
+<dl>
+<dt><b>dubious</b></dt><dd>
+Not a policy matter
+</dd>
+<dt><b>ctte</b></dt><dd>
+Referred to the Technical Committee (tech-ctte)
+</dd>
+<dt><b>devel</b></dt><dd>
+Referred to the developer body
+</dd>
+<dt><b>delegate</b></dt><dd>
+Rejected by a Policy delegate
+</dd>
+<dt><b>obsolete</b></dt><dd>
+The proposal timed out without a conclusion
+
+</dd>
+</dl>
+
+<p>What needs to happen next: The bug should be closed once a final
+resolution is reached, or retagged to an appropriate state if that
+final resolution reverses the decision to reject the proposal.
+</p>
+</div>
+</div>
+
+</div>
+
+<div id="outline-container-3" class="outline-2">
+<h2 id="sec-3">Other Tags </h2>
+<div class="outline-text-2" id="text-3">
+
+
+<p>
+All Policy bugs are additionally categorized by class of bug.
+</p>
+<p>
+The normative tag is used for bugs that make normative changes to
+Policy, meaning that the dictates of Policy will change in some
+fashion as part of the resolution of the bug if the proposal is
+accepted. The full process is followed for such bugs.
+<a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=normative">TAG: normative</a>
+</p>
+<p>
+The informative tag is used for bugs about wording issues, typos,
+informative footnotes, or other changes that do not affect the formal
+dictates of Policy, just the presentation. The same tags are used for
+these bugs for convenience, but the Policy maintainers may make
+informative changes without following the full process. Informative
+bugs fall under their discretion.
+<a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=informative">TAG: informative</a>
+</p>
+<p>
+The packaging tag is used for bugs about the packaging and build
+process of the debian-policy Debian package. These bugs do not follow
+the normal process and will not have the other tags except for pending
+and wontfix (used with their normal meanings).
+<a href="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=packaging">TAG: packaging</a>
+</p></div>
+</div>
+<div id="postamble">
+<p class="author"> Author: Margarita Manterola, Clint Adams, Russ Allbery, and Manoj Srivastava
+<a href="mailto:srivasta@debian.org"><srivasta@debian.org></a>
+</p>
+<p class="date"> Date: 2009-09-13 16:13:52 CDT</p>
+<p class="creator">HTML generated by org-mode 6.30trans in emacs 23</p>
+</div>
+</div>
+</body>
+</html>
--- /dev/null
+-*- mode: org; fill-column: 78 -*-
+#+STARTUP: showall
+#+STARTUP: lognotedone lognotestate
+#+OPTIONS: H:4 toc:2
+#+TITLE: Debian Policy changes process
+#+AUTHOR: Margarita Manterola, Clint Adams, Russ Allbery, and Manoj Srivastava
+#+EMAIL: srivasta@debian.org
+#+OPTIONS: H:3 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t TeX:t LaTeX:nil skip:t d:nil tags:not-in-toc
+#+LINK_HOME: http://wiki.debian.org/Teams/Policy
+#+LINK_UP: http://www.debian.org/
+
+\usepackage{landscape}
+
+\setlength{\oddsidemargin}{0in} % default=0in
+\setlength{\textwidth}{9in} % default=9in
+
+\setlength{\columnsep}{0.5in} % default=10pt
+\setlength{\columnseprule}{1pt} % default=0pt (no line)
+
+\setlength{\textheight}{5.85in} % default=5.15in
+\setlength{\topmargin}{-0.15in} % default=0.20in
+\setlength{\headsep}{0.25in} % default=0.35in
+
+\setlength{\parskip}{1.2ex}
+\setlength{\parindent}{0mm}
+\pagestyle{empty}
+
+\setlength{\headheight}{0pt}
+\setlength{\headsep}{0pt}
+\setlength{\footskip}{5pt}
+\setlength{\textheight}{9.0in}
+\setlength{\textwidth}{6.5in}
+
+To introduce a change in the current DebianPolicy, the change proposal
+has to go through a certain process.
+
+* Change Goals
+
++ The change should be technically correct, and consistent with the
+ rest of the policy document. This means no legislating the value of
+ π. This also means that the proposed solution be known to work;
+ iterative design processes do not belong in policy.
++ The change should not be too disruptive; if very many packages
+ become instantly buggy, then instead there should be a transition
+ plan. Exceptions should be rare (only if the current state is really
+ untenable), and probably blessed by the TC.
++ The change has to be reviewed in depth, in the open, where any one
+ may contribute; a publicly accessible, archived, open mailing list.
++ Proposal should be addressed in a timely fashion.
++ Any domain experts should be consulted, since not every policy
+ mailing list subscriber is an expert on everything, including policy
+ maintainers.
++ The goal is rough consensus on the change, which should not be hard
+ if the matter is technical. Technical issues where there is no
+ agreement should be referred to the TC; non-technical issues should
+ be referred to the whole developer body, and perhaps general
+ resolutions lie down that path.
++ Package maintainers whose packages may be impacted should have
+ access to policy change proposals, even if they do not subscribe to
+ policy mailing lists (policy gazette?).
+
+* Current Process
+
+Each suggested change goes through different states. These states are
+denoted through either usertags of the
+[[mailto:debian-policy@packages.debian.org][debian-policy@packages.debian.org]] user or, for patch, pending, and
+wontfix, regular tags.
+
+[[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done][Current list of bugs]]
+
+The Policy delegates are responsible for managing the tags on bugs and
+will update tags as new bugs are submitted or as activity happens on
+bugs. All Debian Developers should feel free to add the seconded tag
+as described below. Other tags should be changed with the coordination
+of the Policy Team.
+
+** State A: Issue raised
+
+Detect need, like gaps/flaws in current policy, or a new rule should
+be added. Any user or developer may start this step. There is a
+decision point here, not all issues are in scope of policy.
+[[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&tag=issue][TAG: issue]]
+
+What needs to happen next: If this is in scope for Policy, discuss the
+issue and possible solutions, moving to the discussion tag, or if the
+matter is sufficiently clear, go directly to a proposal for how to
+address it, moving to the proposal tag. If this is not in scope for
+Policy, close the bug.
+
+** State B: Discussion
+
+Discuss remedy. Alternate proposals. Discussion guided by
+delegates. There should be a clear time limit to this stage, but as
+yet we have not set one.
+[[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=discussion][TAG: discussion]]
+
+What needs to happen next: Reach a conclusion and consensus in the
+discussion and make a final proposal for what should be changed (if
+anything), moving to the proposal tag.
+
+** State D: Proposal
+
+A final proposal has emerged from the discussion, and there is a rough
+consensus on how to proceed to resolve the issue.
+[[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=proposal][TAG: proposal]]
+
+What needs to happen next: Provided that the rough consensus persists,
+develop a patch against the current Policy document with specific
+wording of the change. Often this is done in conjunction with the
+proposal, in which case one may skip this step and move directly to
+patch tag.
+
+** State E: Wording proposed
+
+A patch against the Policy document reflecting the consensus has been
+created and is waiting for formal seconds. The standard patch tag is
+used for this state, since it's essentially equivalent to the standard
+meaning of that tag.
+[[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=patch][TAG: patch]]
+
+What needs to happen next: The proposal needs to be reviewed and
+seconded. Any Debian developer who agrees with the change and the
+conclusion of rough consensus from the discussion should say so in the
+bug log by seconding the proposal.
+
+** State F: Seconded
+
+The proposal is signed off on by N Debian Developers. To start with,
+we're going with N=3, meaning that if three Debian Developers agree,
+not just with the proposal but with the conclusion that it reflects
+consensus and addresses the original issue -- it is considered
+eligible for inclusion in the next version of Policy. Since Policy is
+partly a technical project governance method, one must be a Debian
+Developer to formally second, although review and discussion is
+welcome from anyone. Once this tag has been applied, the bug is
+waiting for a Policy team member to apply the patch to the package
+repository.
+[[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=seconded][TAG: seconded]]
+
+What needs to happen next: A Policy maintainer does the final review
+and confirmation, and then applies the patch for the next Policy
+release.
+
+This tag is not used very much because normally a Policy maintainer
+applies the patch and moves the proposal to the next state once enough
+seconds are reached.
+
+** State G: Accepted
+
+Change accepted, will be in next upload. The standard pending tag is
+used for this state since it matches the regular meaning of
+pending.
+[[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=pending][TAG: pending]]
+
+What needs to happen next: The bug is now in the waiting queue for the
+next Policy release, and there's nothing left to do except for upload
+a new version of Policy.
+
+** State H: Reject
+
+Rejected proposals. The standard wontfix is used for this
+state. Normally, bugs in this state will not remain open; instead, a
+Policy team member will close them with an explanation. The submitter
+may then appeal to the tech-ctte if they so desire. Alternately,
+issues appealed to the tech-ctte may remain open with this tag while
+that appeal proceeds.
+[[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=rejected][TAG: wontfix]]
+
+We may use one of the following tags here, but to date we have only
+used dubious and ctte. It's not clear whether we need more tags for
+this tage.
+
++ *dubious* :: Not a policy matter
++ *ctte* :: Referred to the Technical Committee (tech-ctte)
++ *devel* :: Referred to the developer body
++ *delegate* :: Rejected by a Policy delegate
++ *obsolete* :: The proposal timed out without a conclusion
+
+What needs to happen next: The bug should be closed once a final
+resolution is reached, or retagged to an appropriate state if that
+final resolution reverses the decision to reject the proposal.
+
+* Other Tags
+
+All Policy bugs are additionally categorized by class of bug.
+
+The normative tag is used for bugs that make normative changes to
+Policy, meaning that the dictates of Policy will change in some
+fashion as part of the resolution of the bug if the proposal is
+accepted. The full process is followed for such bugs.
+[[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=normative][TAG: normative]]
+
+The informative tag is used for bugs about wording issues, typos,
+informative footnotes, or other changes that do not affect the formal
+dictates of Policy, just the presentation. The same tags are used for
+these bugs for convenience, but the Policy maintainers may make
+informative changes without following the full process. Informative
+bugs fall under their discretion.
+[[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=informative][TAG: informative]]
+
+The packaging tag is used for bugs about the packaging and build
+process of the debian-policy Debian package. These bugs do not follow
+the normal process and will not have the other tags except for pending
+and wontfix (used with their normal meanings).
+[[http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=packaging][TAG: packaging]]
--- /dev/null
+ Debian Policy changes process
+ =============================
+
+Author: Margarita Manterola, Clint Adams, Russ Allbery, and Manoj Srivastava <srivasta@debian.org>
+Date: 2009-09-13 01:17:13 CDT
+
+
+Change Goals
+~~~~~~~~~~~~~
+
++ The change should be technically correct, and consistent with the
+ rest of the policy document. This means no legislating the value of
+ π. This also means that the proposed solution be known to work;
+ iterative design processes do not belong in policy.
++ The change should not be too disruptive; if very many packages
+ become instantly buggy, then instead there should be a transition
+ plan. Exceptions should be rare (only if the current state is really
+ untenable), and probably blessed by the TC.
++ The change has to be reviewed in depth, in the open, where any one
+ may contribute; a publicly accessible, archived, open mailing list.
++ Proposal should be addressed in a timely fashion.
++ Any domain experts should be consulted, since not every policy
+ mailing list subscriber is an expert on everything, including policy
+ maintainers.
++ The goal is rough consensus on the change, which should not be hard
+ if the matter is technical. Technical issues where there is no
+ agreement should be referred to the TC; non-technical issues should
+ be referred to the whole developer body, and perhaps general
+ resolutions lie down that path.
++ Package maintainers whose packages may be impacted should have
+ access to policy change proposals, even if they do not subscribe to
+ policy mailing lists (policy gazette?).
+
+Current Process
+~~~~~~~~~~~~~~~~
+
+Each suggested change goes through different states. These states are
+denoted through either usertags of the
+[debian-policy@packages.debian.org] user or, for patch, pending, and
+wontfix, regular tags.
+
+[Current list of bugs]
+
+The Policy delegates are responsible for managing the tags on bugs and
+will update tags as new bugs are submitted or as activity happens on
+bugs. All Debian Developers should feel free to add the seconded tag
+as described below. Other tags should be changed with the coordination
+of the Policy Team.
+
+
+[debian-policy@packages.debian.org]: mailto:debian-policy@packages.debian.org
+[Current list of bugs]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done
+
+State A: Issue raised
+======================
+
+Detect need, like gaps/flaws in current policy, or a new rule should
+be added. Any user or developer may start this step. There is a
+decision point here, not all issues are in scope of policy.
+[TAG: issue]
+
+What needs to happen next: If this is in scope for Policy, discuss the
+issue and possible solutions, moving to the discussion tag, or if the
+matter is sufficiently clear, go directly to a proposal for how to
+address it, moving to the proposal tag. If this is not in scope for
+Policy, close the bug.
+
+
+[TAG: issue]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&tag=issue
+
+State B: Discussion
+====================
+
+Discuss remedy. Alternate proposals. Discussion guided by
+delegates. There should be a clear time limit to this stage, but as
+yet we have not set one.
+[TAG: discussion]
+
+What needs to happen next: Reach a conclusion and consensus in the
+discussion and make a final proposal for what should be changed (if
+anything), moving to the proposal tag.
+
+
+[TAG: discussion]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=discussion
+
+State D: Proposal
+==================
+
+A final proposal has emerged from the discussion, and there is a rough
+consensus on how to proceed to resolve the issue.
+[TAG: proposal]
+
+What needs to happen next: Provided that the rough consensus persists,
+develop a patch against the current Policy document with specific
+wording of the change. Often this is done in conjunction with the
+proposal, in which case one may skip this step and move directly to
+patch tag.
+
+
+[TAG: proposal]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=proposal
+
+State E: Wording proposed
+==========================
+
+A patch against the Policy document reflecting the consensus has been
+created and is waiting for formal seconds. The standard patch tag is
+used for this state, since it's essentially equivalent to the standard
+meaning of that tag.
+[TAG: patch]
+
+What needs to happen next: The proposal needs to be reviewed and
+seconded. Any Debian developer who agrees with the change and the
+conclusion of rough consensus from the discussion should say so in the
+bug log by seconding the proposal.
+
+
+[TAG: patch]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=patch
+
+State F: Seconded
+==================
+
+The proposal is signed off on by N Debian Developers. To start with,
+we're going with N=3, meaning that if three Debian Developers agree,
+not just with the proposal but with the conclusion that it reflects
+consensus and addresses the original issue -- it is considered
+eligible for inclusion in the next version of Policy. Since Policy is
+partly a technical project governance method, one must be a Debian
+Developer to formally second, although review and discussion is
+welcome from anyone. Once this tag has been applied, the bug is
+waiting for a Policy team member to apply the patch to the package
+repository.
+[TAG: seconded]
+
+What needs to happen next: A Policy maintainer does the final review
+and confirmation, and then applies the patch for the next Policy
+release.
+
+This tag is not used very much because normally a Policy maintainer
+applies the patch and moves the proposal to the next state once enough
+seconds are reached.
+
+
+[TAG: seconded]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=seconded
+
+State G: Accepted
+==================
+
+Change accepted, will be in next upload. The standard pending tag is
+used for this state since it matches the regular meaning of
+pending.
+[TAG: pending]
+
+What needs to happen next: The bug is now in the waiting queue for the
+next Policy release, and there's nothing left to do except for upload
+a new version of Policy.
+
+
+[TAG: pending]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=pending
+
+State H: Reject
+================
+
+Rejected proposals. The standard wontfix is used for this
+state. Normally, bugs in this state will not remain open; instead, a
+Policy team member will close them with an explanation. The submitter
+may then appeal to the tech-ctte if they so desire. Alternately,
+issues appealed to the tech-ctte may remain open with this tag while
+that appeal proceeds.
+[TAG: wontfix]
+
+We may use one of the following tags here, but to date we have only
+used dubious and ctte. It's not clear whether we need more tags for
+this tage.
+
+*dubious*: Not a policy matter
+*ctte*: Referred to the Technical Committee (tech-ctte)
+*devel*: Referred to the developer body
+*delegate*: Rejected by a Policy delegate
+*obsolete*: The proposal timed out without a conclusion
+
+What needs to happen next: The bug should be closed once a final
+resolution is reached, or retagged to an appropriate state if that
+final resolution reverses the decision to reject the proposal.
+
+
+[TAG: wontfix]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=rejected
+
+Other Tags
+~~~~~~~~~~~
+
+All Policy bugs are additionally categorized by class of bug.
+
+The normative tag is used for bugs that make normative changes to
+Policy, meaning that the dictates of Policy will change in some
+fashion as part of the resolution of the bug if the proposal is
+accepted. The full process is followed for such bugs.
+[TAG: normative]
+
+The informative tag is used for bugs about wording issues, typos,
+informative footnotes, or other changes that do not affect the formal
+dictates of Policy, just the presentation. The same tags are used for
+these bugs for convenience, but the Policy maintainers may make
+informative changes without following the full process. Informative
+bugs fall under their discretion.
+[TAG: informative]
+
+The packaging tag is used for bugs about the packaging and build
+process of the debian-policy Debian package. These bugs do not follow
+the normal process and will not have the other tags except for pending
+and wontfix (used with their normal meanings).
+[TAG: packaging]
+
+[TAG: normative]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=normative
+[TAG: informative]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=informative
+[TAG: packaging]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=packaging
+
--- /dev/null
+(setq
+ org-export-html-style-include-default nil
+ org-export-html-style
+ "
+<style type=\"text/css\">
+ html { font-family: Times, serif; font-size: 12pt; }
+ .title { text-align: center; }
+ p.verse { margin-left: 3% }
+ pre {
+ border: 1pt solid #AEBDCC;
+ color: #000000;
+ background-color: LightSlateGray;
+ padding: 5pt;
+ font-family: \"Courier New\", courier, monospace;
+ font-size: 90%;
+ overflow:auto;
+ }
+ dt { font-weight: bold; }
+ div.figure { padding: 0.5em; }
+ div.figure p { text-align: center; }
+ .linenr { font-size:smaller }
+ .code-highlighted {background-color:#ffff00;}
+ .org-info-js_info-navigation { border-style:none; }
+ #org-info-js_console-label { font-size:10px; font-weight:bold;
+ white-space:nowrap; }
+ .org-info-js_search-highlight {background-color:#ffff00; color:#000000;
+ font-weight:bold; }
+
+ body {
+ color: DarkSlateGrey;
+ background-color: gainsboro;
+ font-family: Palatino, \"Palatino Linotype\", \"Hoefler Text\", \"Times New Roman\", Times, Georgia, Utopia, serif;
+ }
+ .org-agenda-date { color: #87cefa; }
+ .org-agenda-structure { color: #87cefa; }
+ .org-scheduled { color: #98fb98; }
+ .org-scheduled-previously { color: #ff7f24; }
+ .org-scheduled-today { color: #98fb98; }
+ .org-tag { font-weight: bold; }
+ .org-todo {
+ color: #ffc0cb;
+ font-weight: bold;
+ }
+
+ a {
+ color: inherit;
+ background-color: inherit;
+ font: inherit;
+ text-decoration: inherit;
+ }
+ a:hover { text-decoration: underline; }
+ .todo { font-weight:bold; }
+ .done { font-weight:bold; }
+ .TODO { color:red; }
+ .WAITING { color:orange; }
+ .DONE { color:green; }
+ .timestamp { color: grey }
+ .timestamp-kwd { color: CadetBlue }
+ .tag { background-color:lightblue; font-weight:normal }
+ .target { background-color: lavender; }
+table {
+ border-collapse: collapse; /*separate; */
+ border: outset 3pt;
+ border-spacing: 0pt;
+ /* border-spacing: 5pt; */
+ }
+table td { vertical-align: top; border: 1px solid; }
+table th { vertical-align: top; border: 2px solid; }
+</style>
+<script =\"text/javascript\" language=\"JavaScript\" src=\"/styles/org-info.js\"></script>
+<script type=\"text/javascript\" language=\"JavaScript\">
+/* <![CDATA[ */
+org_html_manager.set(\"LOCAL_TOC\", 0);
+org_html_manager.set(\"VIEW_BUTTONS\", 1);
+org_html_manager.set(\"VIEW\", \"info\");
+org_html_manager.set(\"TOC\", 1);
+org_html_manager.set(\"MOUSE_HINT\", \"underline\"); // could be a background-color like #eeeeee
+org_html_manager.setup ();
+/* ]]> */
+</script>
+")
--- /dev/null
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml"
+lang="en" xml:lang="en">
+<head>
+<div style="text-align:right;font-size:70%;white-space:nowrap;">
+ <a accesskey="h" href="http://www.debian.org/"> UP </a>
+ |
+ <a accesskey="H" href="http://wiki.debian.org/Teams/Policy"> HOME </a>
+</div>
+
+<title>Debian Policy</title>
+<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
+<meta name="generator" content="Org-mode"/>
+<meta name="generated" content="2009-10-05 00:20:29 CDT"/>
+<meta name="author" content="Manoj Srivastava And Russ Allbery"/>
+<meta name="description" content=""/>
+<meta name="keywords" content=""/>
+
+<style type="text/css">
+ html { font-family: Times, serif; font-size: 12pt; }
+ .title { text-align: center; }
+ p.verse { margin-left: 3% }
+ pre {
+ border: 1pt solid #AEBDCC;
+ color: #000000;
+ background-color: LightSlateGray;
+ padding: 5pt;
+ font-family: "Courier New", courier, monospace;
+ font-size: 90%;
+ overflow:auto;
+ }
+ dt { font-weight: bold; }
+ div.figure { padding: 0.5em; }
+ div.figure p { text-align: center; }
+ .linenr { font-size:smaller }
+ .code-highlighted {background-color:#ffff00;}
+ .org-info-js_info-navigation { border-style:none; }
+ #org-info-js_console-label { font-size:10px; font-weight:bold;
+ white-space:nowrap; }
+ .org-info-js_search-highlight {background-color:#ffff00; color:#000000;
+ font-weight:bold; }
+
+ body {
+ color: DarkSlateGrey;
+ background-color: gainsboro;
+ font-family: Palatino, "Palatino Linotype", "Hoefler Text", "Times New Roman", Times, Georgia, Utopia, serif;
+ }
+ .org-agenda-date { color: #87cefa; }
+ .org-agenda-structure { color: #87cefa; }
+ .org-scheduled { color: #98fb98; }
+ .org-scheduled-previously { color: #ff7f24; }
+ .org-scheduled-today { color: #98fb98; }
+ .org-tag { font-weight: bold; }
+ .org-todo {
+ color: #ffc0cb;
+ font-weight: bold;
+ }
+
+ a {
+ color: inherit;
+ background-color: inherit;
+ font: inherit;
+ text-decoration: inherit;
+ }
+ a:hover { text-decoration: underline; }
+ .todo { font-weight:bold; }
+ .done { font-weight:bold; }
+ .TODO { color:red; }
+ .WAITING { color:orange; }
+ .DONE { color:green; }
+ .timestamp { color: grey }
+ .timestamp-kwd { color: CadetBlue }
+ .tag { background-color:lightblue; font-weight:normal }
+ .target { background-color: lavender; }
+table {
+ border-collapse: collapse; /*separate; */
+ border: outset 3pt;
+ border-spacing: 0pt;
+ /* border-spacing: 5pt; */
+ }
+table td { vertical-align: top; border: 1px solid; }
+table th { vertical-align: top; border: 2px solid; }
+</style>
+<script ="text/javascript" language="JavaScript" src="/styles/org-info.js"></script>
+<script type="text/javascript" language="JavaScript">
+/* <![CDATA[ */
+org_html_manager.set("LOCAL_TOC", 0);
+org_html_manager.set("VIEW_BUTTONS", 1);
+org_html_manager.set("VIEW", "info");
+org_html_manager.set("TOC", 1);
+org_html_manager.set("MOUSE_HINT", "underline"); // could be a background-color like #eeeeee
+org_html_manager.setup ();
+/* ]]> */
+</script>
+
+<script type="text/javascript">
+<!--/*--><![CDATA[/*><!--*/
+ function CodeHighlightOn(elem, id)
+ {
+ var target = document.getElementById(id);
+ if(null != target) {
+ elem.cacheClassElem = elem.className;
+ elem.cacheClassTarget = target.className;
+ target.className = "code-highlighted";
+ elem.className = "code-highlighted";
+ }
+ }
+ function CodeHighlightOff(elem, id)
+ {
+ var target = document.getElementById(id);
+ if(elem.cacheClassElem)
+ elem.className = elem.cacheClassElem;
+ if(elem.cacheClassTarget)
+ target.className = elem.cacheClassTarget;
+ }
+/*]]>*///-->
+</script>
+</head>
+<body>
+<div id="content">
+<h1 class="title">Debian Policy</h1>
+
+
+<div id="outline-container-1" class="outline-2">
+<h2 id="sec-1">Infrastructure </h2>
+<div class="outline-text-2" id="text-1">
+
+
+<ul>
+<li>
+Website:: <a href="http://www.debian.org/doc/devel-manuals#policy">http://www.debian.org/doc/devel-manuals#policy</a>
+</li>
+<li>
+Mailing list:: debian-policy@lists.debian.org lists
+</li>
+<li>
+Source Code::
+<ul>
+<li>
+git clone git://git.debian.org/git/dbnpolicy/policy.git
+</li>
+<li>
+Browser: <a href="http://git.debian.org/?p=dbnpolicy/policy.git">http://git.debian.org/?p=dbnpolicy/policy.git</a>
+</li>
+</ul>
+</li>
+<li>
+Unix group:: dbnpolicy
+</li>
+<li>
+Alioth Project:: <a href="http://alioth.debian.org/projects/dbnpolicy">http://alioth.debian.org/projects/dbnpolicy</a> (exists
+to manage the repository but not otherwise used)
+
+</li>
+</ul>
+
+</div>
+
+<div id="outline-container-1.1" class="outline-3">
+<h3 id="sec-1.1">Interacting with the team </h3>
+<div class="outline-text-3" id="text-1.1">
+
+
+<ul>
+<li>
+Email contact:: <a href="mailto:debian-policy@lists.debian.org">mailto:debian-policy@lists.debian.org</a>
+</li>
+<li>
+Request tracker:: <a href="http://bugs.debian.org/src:debian-policy">http://bugs.debian.org/src:debian-policy</a>
+
+</li>
+</ul>
+
+<p>Debian Policy uses a formal procedure and a set of user tags to manage
+the lifecycle of change proposals. For definitions of those tags and
+proposal states and information about what the next step is for each
+phase, see <a href="./Process.html">Policy changes process</a>.
+</p>
+<p>
+Once the wording for a change has been finalized, please send a patch
+against the current Git master branch to the bug report, if you're not
+familiar with Git, the following commands are the basic process:
+</p>
+
+
+
+<pre class="src src-Sh">git clone git://git.debian.org/git/dbnpolicy/policy.git
+git checkout -b <local-branch-name>
+
+# edit files, but don't make changes to upgrading-checklist or debian/changelog
+git add <files>
+git commit
+# repeat as necessary
+
+# update your branch against the current master
+git checkout master
+git pull
+
+git checkout master
+git merge --no-commit <local-branch-name>
+git reset --hard HEAD;
+git checkout <local-branch-name>;
+
+# If there are changes in master that make the branch not apply cleanly, there
+# should have been en error during the merge step above. If there was an
+# error, merge the master branch into the local branch, fix the conflicts, and
+# commit the new version of the local branch.
+ : git merge master
+# Edit files to remove conflict
+ : git commit -s
+
+# Checkout the local branch, to create the patch to send to the policy
+git checkout <local-branch-name>
+dir=$(mktemp -d)
+git format-patch -o $dir -s master
+# check out the patches created in $dir
+git send-email --from <span style="font-style: italic;">"you <<a href="mailto:your@email">your@email</a>>"</span> \
+ --to debian-policy@lists.debian.org \
+ $dir/
+</pre>
+
+
+
+
+<p>
+<local-branch-name> is some convenient name designating your local
+changes. You may want to use some common prefix like local-. You can
+use git format-patch and git send-email if you want, but usually it's
+overkill.
+</p>
+</div>
+</div>
+
+</div>
+
+<div id="outline-container-2" class="outline-2">
+<h2 id="sec-2">Usual Roles </h2>
+<div class="outline-text-2" id="text-2">
+
+
+<p>
+The Debian Policy team are official project delegates (see the DPL
+delegation). All of the Policy team members do basically the same
+work: shepherd proposals, propose wording, and merge changes when
+consensus has been reached. The current delegates are:
+</p>
+<ul>
+<li>
+Russ Allbery
+</li>
+<li>
+Bill Allombert
+</li>
+<li>
+Andrew McMillan
+</li>
+<li>
+Manoj Srivastava
+</li>
+<li>
+Colin Watson (cjwatson)
+
+</li>
+</ul>
+
+<p>The special tasks of Policy delegates are:
+</p>
+<ul>
+<li>
+Commit access to the Git repository and uploads of the debian-policy
+package itself, which makes them responsible for debian-policy as a
+package in Debian and for making final decisions about when a new
+version is released and what bits go into it.
+</li>
+<li>
+Rejecting proposals. Anyone can argue against a proposal, but only
+Policy delegates can formally reject it.
+</li>
+<li>
+Counting seconds and weighing objections to proposals to determine
+whether the proposal has sufficient support to be included.
+
+</li>
+</ul>
+
+<p>Everything else can be done by anyone, or any DD (depending on the
+outcome of the discussion about seconding). We explicitly want any
+Debian DD to review and second or object to proposals. The more
+participation, the better. Many other people are active on the Policy
+mailing list without being project delegates.
+</p>
+</div>
+
+</div>
+
+<div id="outline-container-3" class="outline-2">
+<h2 id="sec-3">Task description </h2>
+<div class="outline-text-2" id="text-3">
+
+
+<p>
+The Debian Policy team is responsible for maintaining and coordinating
+updates to the technical Policy manuals for the project. The primary
+output of the team is the Debian Policy Manual and the assorted
+subpolicies, released as the debian-policy Debian package and also
+published at <a href="http://www.debian.org/doc/">http://www.debian.org/doc/</a>.
+</p>
+<p>
+In addition to the main technical manual, the team currently also maintains:
+</p>
+<ul>
+<li>
+<a href="http://www.debian.org/doc/packaging-manuals/menu-policy/">Debian Menu sub-policy</a>
+</li>
+<li>
+<a href="http://www.debian.org/doc/packaging-manuals/perl-policy/">Debian Perl Policy</a>
+</li>
+<li>
+<a href="http://www.debian.org/doc/packaging-manuals/mime-policy/">Debian MIME support sub-policy</a>
+</li>
+<li>
+<a href="http://www.debian.org/doc/packaging-manuals/debconf_specification.html">Debconf Specification</a>
+</li>
+<li>
+<a href="http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt">Authoritative list of virtual package names </a>
+
+</li>
+</ul>
+
+<p>These documents are maintained using the <a href="./Process.html">Policy changes process</a>, and
+the current state of all change proposals is tracked using the
+<a href="http://bugs.debian.org/src:debian-policy">debian-policy BTS</a>.
+</p>
+</div>
+
+</div>
+
+<div id="outline-container-4" class="outline-2">
+<h2 id="sec-4">Get involved </h2>
+<div class="outline-text-2" id="text-4">
+
+
+<p>
+The best way to help is to review the <a href="http://bugs.debian.org/src:debian-policy">current open bugs</a>, pick a bug
+that no one is currently shepherding (ask on
+<a href="mailto:debian-policy@lists.debian.org">debian-policy@lists.debian.org</a> if you're not sure if a particular bug
+is being shepherded), and help it through the change process. This
+will involve guiding the discussion, seeking additional input
+(particularly from experts in the area being discussed), possibly
+raising the issue on other mailing lists, proposing or getting other
+people to propose specific wording changes, and writing diffs against
+the current Policy document. All of the steps of <a href="./Process.html">Policy changes process</a>
+can be done by people other than Policy team members except
+the final acceptance steps and almost every change can be worked on
+independently, so there's a lot of opportunity for people to help.
+</p>
+<p>
+There are also some other, larger projects:
+</p>
+<ul>
+<li>
+Policy is currently maintained in DebianDoc-SGML, which is no longer
+very actively maintained and isn't a widely used or understood
+format. The most logical replacement would be DocBook. However,
+DocBook is a huge language with many tags and options, making it
+rather overwhelming. We badly need someone with DocBook experience
+to write a style guide specifying exactly which tags should be used
+and what they should be used for so that we can limit ourselves to
+an easy-to-understand and documented subset of the language.
+</li>
+<li>
+Policy contains several appendices which are really documentation of
+how parts of the dpkg system works rather than technical
+Policy. Those appendices should be removed from the Policy document
+and maintained elsewhere, probably as part of dpkg, and any Policy
+statements in them moved into the main document. This project will
+require reviewing the current contents of the appendices and feeding
+the useful bits that aren't currently documented back to the dpkg
+team as documentation patches.
+</li>
+<li>
+Policy has grown organically over the years and suffers from
+organizational issues because of it. It also doesn't make use of the
+abilities that a current XML language might give us, such as being
+able to extract useful portions of the document (all <b>must</b>
+directives, for example). There has been quite a bit of discussion
+of a new format that would allow for this, probably as part of
+switching to DocBook, but as yet such a reorganization and reworking
+has not been started.
+
+</li>
+</ul>
+
+<p>If you want to work on any of these projects, please mail
+<a href="mailto:debian-policy@lists.debian.org">debian-policy@lists.debian.org </a> for more information. We'll be happy to
+help you get started.
+</p>
+
+</div>
+
+<div id="outline-container-4.1" class="outline-3">
+<h3 id="sec-4.1">Maintenance procedures </h3>
+<div class="outline-text-3" id="text-4.1">
+
+
+</div>
+
+</div>
+
+<div id="outline-container-4.2" class="outline-3">
+<h3 id="sec-4.2">Repository layout </h3>
+<div class="outline-text-3" id="text-4.2">
+
+
+<p>
+The Git repository used for Debian Policy has the following branches:
+</p>
+<ul>
+<li>
+ master:: the current accepted changes that will be in the next release
+</li>
+<li>
+ bug<number>-<user>:: changes addressing bug <number>, shepherded by <user>
+</li>
+<li>
+ rra:: old history of Russ's arch repository, now frozen
+</li>
+<li>
+ srivasta:: old history of Manoj's arch repository
+
+</li>
+</ul>
+</div>
+
+</div>
+
+<div id="outline-container-4.3" class="outline-3">
+<h3 id="sec-4.3">Managing a bug </h3>
+<div class="outline-text-3" id="text-4.3">
+
+
+<p>
+The process used by Policy team members to manage a bug, once there is
+proposed wording, is:
+</p>
+<ul>
+<li>
+Create a bug<number>-<user> branch for the bug, where <number> is
+the bug number in the BTS and <user> is a designator of the Policy
+team member who is shepherding the bug.
+</li>
+<li>
+Commit wording changes in that branch until consensus is
+achieved. Do not modify debian/changelog or upgrading-checklist.html
+during this phase. Use the BTS to track who proposed the wording and
+who seconded it.
+</li>
+<li>
+git pull master to make sure you have the latest version.
+</li>
+<li>
+Once the change has been approved by enough people, git merge the
+branch into master immediately after making the final commit adding
+the changelog entry to minimize conflicts.
+</li>
+<li>
+add the debian/changelog and upgrading-checklist.html changes, and
+commit to master.
+</li>
+<li>
+Push master out so other people may merge in their own bug branches
+without conflicts.
+</li>
+<li>
+Tag the bug as pending and remove other process tags.
+</li>
+<li>
+Delete the now-merged branch.
+
+</li>
+</ul>
+
+<p>The Git commands used for this workflow are:
+</p>
+
+
+<pre class="src src-Sh">git checkout -b bug12345-rra master
+# edit files
+# git add files
+git commit
+git push origin bug12345-rra
+# iterate until good
+# update your local master branch
+git checkout master
+git pull
+
+git checkout master
+git merge --no-commit bug12345-rra
+git reset --hard HEAD;
+
+# If there are changes in master that make the branch not apply cleanly, there
+# should have been en error during the merge step above. If there was an
+# error, merge the master branch into the local branch, fix the conflicts, and
+# commit the new version of the local branch.
+ : git checkout bug12345-rra
+ : git merge master
+# Edit files to remove conflict
+ : git commit -s
+
+git checkout master
+git merge bug12345-rra
+# edit debian/changelog and upgrading-checklist.html
+git add debian/changelog upgrading-checklist.html
+git commit
+git push origin master
+git branch -d bug12345-rra
+git push origin :bug12345-rra
+</pre>
+
+
+
+
+<p>
+For the debian/changelog entry, use the following format:
+</p>
+
+
+<pre class="example">* <document>: <brief change description>
+ Wording: <author of wording>
+ Seconded: <seconder>
+ Seconded: <seconder>
+ Closes: <bug numbers>
+</pre>
+
+
+
+
+<p>
+For example:
+</p>
+
+
+<pre class="example">* 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
+</pre>
+
+
+
+
+</div>
+
+</div>
+
+<div id="outline-container-4.4" class="outline-3">
+<h3 id="sec-4.4">Updating branches </h3>
+<div class="outline-text-3" id="text-4.4">
+
+
+<p>
+After commits to master have been pushed, either by you or by another
+Policy team member, you will generally want to update your working bug
+branches. The equivalent of the following commands should do that:
+</p>
+
+
+
+<pre class="src src-Sh">for i in `git show-ref --heads | awk '{print $2}'`; do
+ j=$(basename $i)
+ if [ <span style="font-style: italic;">"$j"</span> != <span style="font-style: italic;">"master"</span> ]; then
+ git checkout $j && git merge master
+ fi
+done
+git push --all origin
+</pre>
+
+
+
+
+<p>
+assuming that you haven't packed the refs in your repository.
+</p>
+</div>
+
+</div>
+
+<div id="outline-container-4.5" class="outline-3">
+<h3 id="sec-4.5">Making a release </h3>
+<div class="outline-text-3" id="text-4.5">
+
+
+<p>
+For a final Policy release, change UNRELEASED to unstable in
+debian/changelog and update the timestamp to match the final release
+time (dch -r may be helpful for this), update the release date in
+upgrading-checklist.html, update Standards-Version in debian/control,
+and commit that change. Then do the final release build and make sure
+that it builds and installs.
+</p>
+<p>
+Then, tag the repository and push the final changes to Alioth:
+</p>
+
+
+
+<pre class="src src-Sh">git tag -s v3.8.0.0
+git push origin
+git push --tags origin
+</pre>
+
+
+
+
+<p>
+replacing the version number with the version of the release, of course.
+</p>
+<p>
+Finally, announce the new Policy release on debian-devel-announce,
+including in the announcement the upgrading-checklist section for the
+new release.
+</p>
+</div>
+
+</div>
+
+<div id="outline-container-4.6" class="outline-3">
+<h3 id="sec-4.6">Setting release goals </h3>
+<div class="outline-text-3" id="text-4.6">
+
+
+<p>
+Policy has a large bug backlog, and each bug against Policy tends to
+take considerable time and discussion to resolve. I've found it
+useful, when trying to find a place to start, to pick a manageable set
+of bugs and set as a target resolving them completely before the next
+Policy release. Resolving a bug means one of the following:
+</p>
+<ul>
+<li>
+Proposing new language to address the bug that's seconded and approved by
+the readers of the Policy list following the <a href="./Progress.html">Policy changes process</a> (or
+that's accepted by one of the Policy delegates if the change isn't
+normative; i.e., doesn't change the technical meaning of the document).
+</li>
+<li>
+Determining that the bug is not relevant to Policy and closing it.
+</li>
+<li>
+Determining that either there is no consensus that the bug indicates
+a problem, that the solutions that we can currently come up with are
+good solutions, or that Debian is ready for the change. These bugs
+are tagged wontfix and then closed after a while. A lot of Policy
+bugs fall into this category; just because it would be useful to
+have a policy in some area doesn't mean that we're ready to make
+one, and keeping the bugs open against Policy makes it difficult to
+tell what requires work. If the problem is worth writing a policy
+for, it will come up again later when hopefully the project
+consensus is more mature.
+
+</li>
+</ul>
+
+<p>Anyone can pick bugs and work resolve them. The final determination to
+accept a wording change or reject a bug will be made by a Policy
+delegate, but if a patch is already written and seconded, or if a
+summary of why a bug is not ready to be acted on is already written,
+the work is much easier for the Policy delegate.
+</p>
+<p>
+One of the best ways to help out is to pick one or two bugs (checking
+on the Policy list first), say that you'll make resolving them a goal
+for the next release, and guide the discussion until the bugs can
+reach one of the resolution states above.
+</p></div>
+</div>
+</div>
+<div id="postamble">
+<p class="author"> Author: Manoj Srivastava And Russ Allbery
+<a href="mailto:srivasta@debian.org"><srivasta@debian.org></a>
+</p>
+<p class="date"> Date: 2009-10-05 00:20:29 CDT</p>
+<p class="creator">HTML generated by org-mode 6.31trans in emacs 23</p>
+</div>
+</div>
+</body>
+</html>
--- /dev/null
+-*- mode: org; fill-column: 78 -*-
+#+STARTUP: showall
+#+STARTUP: lognotedone lognotestate
+#+OPTIONS: H:4 toc:2
+#+TITLE: Debian Policy
+#+AUTHOR: Manoj Srivastava And Russ Allbery
+#+EMAIL: srivasta@debian.org
+#+OPTIONS: H:3 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t TeX:t LaTeX:nil skip:t d:nil tags:not-in-toc
+#+LINK_HOME: http://wiki.debian.org/Teams/Policy
+#+LINK_UP: http://www.debian.org/
+
+\usepackage{landscape}
+
+\setlength{\oddsidemargin}{0in} % default=0in
+\setlength{\textwidth}{9in} % default=9in
+
+\setlength{\columnsep}{0.5in} % default=10pt
+\setlength{\columnseprule}{1pt} % default=0pt (no line)
+
+\setlength{\textheight}{5.85in} % default=5.15in
+\setlength{\topmargin}{-0.15in} % default=0.20in
+\setlength{\headsep}{0.25in} % default=0.35in
+
+\setlength{\parskip}{1.2ex}
+\setlength{\parindent}{0mm}
+\pagestyle{empty}
+
+\setlength{\headheight}{0pt}
+\setlength{\headsep}{0pt}
+\setlength{\footskip}{5pt}
+\setlength{\textheight}{9.0in}
+\setlength{\textwidth}{6.5in}
+
+
+* Infrastructure
+
++ Website:: http://www.debian.org/doc/devel-manuals#policy
++ Mailing list:: debian-policy@lists.debian.org lists
++ Source Code::
+ * git clone git://git.debian.org/git/dbnpolicy/policy.git
+ * Browser: http://git.debian.org/?p=dbnpolicy/policy.git
++ Unix group:: dbnpolicy
++ Alioth Project:: http://alioth.debian.org/projects/dbnpolicy (exists
+ to manage the repository but not otherwise used)
+
+** Interacting with the team
+
++ Email contact:: mailto:debian-policy@lists.debian.org
++ Request tracker:: http://bugs.debian.org/src:debian-policy
+
+Debian Policy uses a formal procedure and a set of user tags to manage
+the lifecycle of change proposals. For definitions of those tags and
+proposal states and information about what the next step is for each
+phase, see [[./Process.org][Policy changes process]].
+
+Once the wording for a change has been finalized, please send a patch
+against the current Git master branch to the bug report, if you're not
+familiar with Git, the following commands are the basic process:
+
+#+BEGIN_SRC Sh
+git clone git://git.debian.org/git/dbnpolicy/policy.git
+git checkout -b <local-branch-name>
+
+# edit files, but don't make changes to upgrading-checklist or debian/changelog
+git add <files>
+git commit
+# repeat as necessary
+
+# update your branch against the current master
+git checkout master
+git pull
+
+git checkout master
+git merge --no-commit <local-branch-name>
+git reset --hard HEAD;
+git checkout <local-branch-name>;
+
+# If there are changes in master that make the branch not apply cleanly, there
+# should have been en error during the merge step above. If there was an
+# error, merge the master branch into the local branch, fix the conflicts, and
+# commit the new version of the local branch.
+ : git merge master
+# Edit files to remove conflict
+ : git commit -s
+
+# Checkout the local branch, to create the patch to send to the policy
+git checkout <local-branch-name>
+dir=$(mktemp -d)
+git format-patch -o $dir -s master
+# check out the patches created in $dir
+git send-email --from "you <your@email>" \
+ --to debian-policy@lists.debian.org \
+ $dir/
+#+END_SRC
+
+<local-branch-name> is some convenient name designating your local
+changes. You may want to use some common prefix like local-. You can
+use git format-patch and git send-email if you want, but usually it's
+overkill.
+
+* Usual Roles
+
+The Debian Policy team are official project delegates (see the DPL
+delegation). All of the Policy team members do basically the same
+work: shepherd proposals, propose wording, and merge changes when
+consensus has been reached. The current delegates are:
+
++ Russ Allbery
++ Bill Allombert
++ Andrew McMillan
++ Manoj Srivastava
++ Colin Watson (cjwatson)
+
+The special tasks of Policy delegates are:
+
++ Commit access to the Git repository and uploads of the debian-policy
+ package itself, which makes them responsible for debian-policy as a
+ package in Debian and for making final decisions about when a new
+ version is released and what bits go into it.
++ Rejecting proposals. Anyone can argue against a proposal, but only
+ Policy delegates can formally reject it.
++ Counting seconds and weighing objections to proposals to determine
+ whether the proposal has sufficient support to be included.
+
+Everything else can be done by anyone, or any DD (depending on the
+outcome of the discussion about seconding). We explicitly want any
+Debian DD to review and second or object to proposals. The more
+participation, the better. Many other people are active on the Policy
+mailing list without being project delegates.
+
+* Task description
+
+The Debian Policy team is responsible for maintaining and coordinating
+updates to the technical Policy manuals for the project. The primary
+output of the team is the Debian Policy Manual and the assorted
+subpolicies, released as the debian-policy Debian package and also
+published at [[http://www.debian.org/doc/]].
+
+In addition to the main technical manual, the team currently also maintains:
+
++ [[http://www.debian.org/doc/packaging-manuals/menu-policy/][Debian Menu sub-policy]]
++ [[http://www.debian.org/doc/packaging-manuals/perl-policy/][Debian Perl Policy]]
++ [[http://www.debian.org/doc/packaging-manuals/mime-policy/][Debian MIME support sub-policy]]
++ [[http://www.debian.org/doc/packaging-manuals/debconf_specification.html][Debconf Specification]]
++ [[http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt][Authoritative list of virtual package names ]]
+
+These documents are maintained using the [[./Process.org][Policy changes process]], and
+the current state of all change proposals is tracked using the
+[[http://bugs.debian.org/src:debian-policy][debian-policy BTS]].
+
+* Get involved
+
+The best way to help is to review the [[http://bugs.debian.org/src:debian-policy][current open bugs]], pick a bug
+that no one is currently shepherding (ask on
+[[mailto:debian-policy@lists.debian.org][debian-policy@lists.debian.org]] if you're not sure if a particular bug
+is being shepherded), and help it through the change process. This
+will involve guiding the discussion, seeking additional input
+(particularly from experts in the area being discussed), possibly
+raising the issue on other mailing lists, proposing or getting other
+people to propose specific wording changes, and writing diffs against
+the current Policy document. All of the steps of [[./Process.org][Policy changes process]]
+can be done by people other than Policy team members except
+the final acceptance steps and almost every change can be worked on
+independently, so there's a lot of opportunity for people to help.
+
+There are also some other, larger projects:
+
++ Policy is currently maintained in DebianDoc-SGML, which is no longer
+ very actively maintained and isn't a widely used or understood
+ format. The most logical replacement would be DocBook. However,
+ DocBook is a huge language with many tags and options, making it
+ rather overwhelming. We badly need someone with DocBook experience
+ to write a style guide specifying exactly which tags should be used
+ and what they should be used for so that we can limit ourselves to
+ an easy-to-understand and documented subset of the language.
++ Policy contains several appendices which are really documentation of
+ how parts of the dpkg system works rather than technical
+ Policy. Those appendices should be removed from the Policy document
+ and maintained elsewhere, probably as part of dpkg, and any Policy
+ statements in them moved into the main document. This project will
+ require reviewing the current contents of the appendices and feeding
+ the useful bits that aren't currently documented back to the dpkg
+ team as documentation patches.
++ Policy has grown organically over the years and suffers from
+ organizational issues because of it. It also doesn't make use of the
+ abilities that a current XML language might give us, such as being
+ able to extract useful portions of the document (all *must*
+ directives, for example). There has been quite a bit of discussion
+ of a new format that would allow for this, probably as part of
+ switching to DocBook, but as yet such a reorganization and reworking
+ has not been started.
+
+If you want to work on any of these projects, please mail
+[[mailto:debian-policy@lists.debian.org][debian-policy@lists.debian.org ]] for more information. We'll be happy to
+help you get started.
+
+** Maintenance procedures
+
+** Repository layout
+
+The Git repository used for Debian Policy has the following branches:
+
++ master:: the current accepted changes that will be in the next release
++ bug<number>-<user>:: changes addressing bug <number>, shepherded by <user>
++ rra:: old history of Russ's arch repository, now frozen
++ srivasta:: old history of Manoj's arch repository
+
+** Managing a bug
+
+The process used by Policy team members to manage a bug, once there is
+proposed wording, is:
+
++ Create a bug<number>-<user> branch for the bug, where <number> is
+ the bug number in the BTS and <user> is a designator of the Policy
+ team member who is shepherding the bug.
++ Commit wording changes in that branch until consensus is
+ achieved. Do not modify debian/changelog or upgrading-checklist.html
+ during this phase. Use the BTS to track who proposed the wording and
+ who seconded it.
++ git pull master to make sure you have the latest version.
++ Once the change has been approved by enough people, git merge the
+ branch into master immediately after making the final commit adding
+ the changelog entry to minimize conflicts.
++ add the debian/changelog and upgrading-checklist.html changes, and
+ commit to master.
++ Push master out so other people may merge in their own bug branches
+ without conflicts.
++ Tag the bug as pending and remove other process tags.
++ Delete the now-merged branch.
+
+The Git commands used for this workflow are:
+#+BEGIN_SRC Sh
+git checkout -b bug12345-rra master
+# edit files
+# git add files
+git commit
+git push origin bug12345-rra
+# iterate until good
+# update your local master branch
+git checkout master
+git pull
+
+git checkout master
+git merge --no-commit bug12345-rra
+git reset --hard HEAD;
+
+# If there are changes in master that make the branch not apply cleanly, there
+# should have been en error during the merge step above. If there was an
+# error, merge the master branch into the local branch, fix the conflicts, and
+# commit the new version of the local branch.
+ : git checkout bug12345-rra
+ : git merge master
+# Edit files to remove conflict
+ : git commit -s
+
+git checkout master
+git merge bug12345-rra
+# edit debian/changelog and upgrading-checklist.html
+git add debian/changelog upgrading-checklist.html
+git commit
+git push origin master
+git branch -d bug12345-rra
+git push origin :bug12345-rra
+#+END_SRC
+
+For the debian/changelog entry, use the following format:
+#+BEGIN_EXAMPLE
+ * <document>: <brief change description>
+ Wording: <author of wording>
+ Seconded: <seconder>
+ Seconded: <seconder>
+ Closes: <bug numbers>
+#+END_EXAMPLE
+
+For example:
+#+BEGIN_EXAMPLE
+ * 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
+#+END_EXAMPLE
+
+** Updating branches
+
+After commits to master have been pushed, either by you or by another
+Policy team member, you will generally want to update your working bug
+branches. The equivalent of the following commands should do that:
+
+#+BEGIN_SRC Sh
+for i in `git show-ref --heads | awk '{print $2}'`; do
+ j=$(basename $i)
+ if [ "$j" != "master" ]; then
+ git checkout $j && git merge master
+ fi
+done
+git push --all origin
+#+END_SRC
+
+assuming that you haven't packed the refs in your repository.
+
+** Making a release
+
+For a final Policy release, change UNRELEASED to unstable in
+debian/changelog and update the timestamp to match the final release
+time (dch -r may be helpful for this), update the release date in
+upgrading-checklist.html, update Standards-Version in debian/control,
+and commit that change. Then do the final release build and make sure
+that it builds and installs.
+
+Then, tag the repository and push the final changes to Alioth:
+
+#+BEGIN_SRC Sh
+git tag -s v3.8.0.0
+git push origin
+git push --tags origin
+#+END_SRC
+
+replacing the version number with the version of the release, of course.
+
+Finally, announce the new Policy release on debian-devel-announce,
+including in the announcement the upgrading-checklist section for the
+new release.
+
+** Setting release goals
+
+Policy has a large bug backlog, and each bug against Policy tends to
+take considerable time and discussion to resolve. I've found it
+useful, when trying to find a place to start, to pick a manageable set
+of bugs and set as a target resolving them completely before the next
+Policy release. Resolving a bug means one of the following:
+
++ Proposing new language to address the bug that's seconded and approved by
+ the readers of the Policy list following the [[./Progress.org][Policy changes process]] (or
+ that's accepted by one of the Policy delegates if the change isn't
+ normative; i.e., doesn't change the technical meaning of the document).
++ Determining that the bug is not relevant to Policy and closing it.
++ Determining that either there is no consensus that the bug indicates
+ a problem, that the solutions that we can currently come up with are
+ good solutions, or that Debian is ready for the change. These bugs
+ are tagged wontfix and then closed after a while. A lot of Policy
+ bugs fall into this category; just because it would be useful to
+ have a policy in some area doesn't mean that we're ready to make
+ one, and keeping the bugs open against Policy makes it difficult to
+ tell what requires work. If the problem is worth writing a policy
+ for, it will come up again later when hopefully the project
+ consensus is more mature.
+
+Anyone can pick bugs and work resolve them. The final determination to
+accept a wording change or reject a bug will be made by a Policy
+delegate, but if a patch is already written and seconded, or if a
+summary of why a bug is not ready to be acted on is already written,
+the work is much easier for the Policy delegate.
+
+One of the best ways to help out is to pick one or two bugs (checking
+on the Policy list first), say that you'll make resolving them a goal
+for the next release, and guide the discussion until the bugs can
+reach one of the resolution states above.
--- /dev/null
+ Debian Policy
+ =============
+
+Author: Manoj Srivastava And Russ Allbery <srivasta@debian.org>
+Date: 2009-09-15 15:48:35 CDT
+
+
+Infrastructure
+~~~~~~~~~~~~~~~
+
++ Website:: [http://www.debian.org/doc/devel-manuals#policy]
++ Mailing list:: debian-policy@lists.debian.org lists
++ Source Code::
+ * git clone git://git.debian.org/git/dbnpolicy/policy.git
+ * Browser: [http://git.debian.org/?p=dbnpolicy/policy.git]
++ Unix group:: dbnpolicy
++ Alioth Project:: [http://alioth.debian.org/projects/dbnpolicy] (exists
+ to manage the repository but not otherwise used)
+
+Interacting with the team
+==========================
+
++ Email contact:: [mailto:debian-policy@lists.debian.org]
++ Request tracker:: [http://bugs.debian.org/src:debian-policy]
+
+Debian Policy uses a formal procedure and a set of user tags to manage
+the lifecycle of change proposals. For definitions of those tags and
+proposal states and information about what the next step is for each
+phase, see [Policy changes process].
+
+Once the wording for a change has been finalized, please send a patch
+against the current Git master branch to the bug report, if you're not
+familiar with Git, the following commands are the basic process:
+
+ git clone git://git.debian.org/git/dbnpolicy/policy.git
+ git checkout -b <local-branch-name>
+
+ # edit files, but don't make changes to upgrading-checklist or debian/changelog
+ git add <files>
+ git commit
+ # repeat as necessary
+
+ # update your branch against the current master
+ git checkout master
+ git pull
+
+ # If there are changes in master that make the branch not apply cleanly:
+ git checkout -b temp master; git merge <local-branch-name>
+ # If error, reset temp, merge master into local; else skip these three lines
+ git reset --hard HEAD;
+ git checkout <local-branch-name>;
+ git merge master
+ # get rid of the temp branch:
+ git branch -D temp
+
+ # Checkout the local branch, to create the patch to send to the policy
+ git checkout <local-branch-name>
+ dir=$(mktemp -d)
+ git format-patch -o $dir -s master
+ # check out the patches created in $dir
+ git send-email --from "you <your@email>" \
+ --to debian-policy@lists.debian.org \
+ $dir/
+
+
+<local-branch-name> is some convenient name designating your local
+changes. You may want to use some common prefix like local-. You can
+use git format-patch and git send-email if you want, but usually it's
+overkill.
+
+
+[Policy changes process]: Process.txt
+
+Usual Roles
+~~~~~~~~~~~~
+
+The Debian Policy team are official project delegates (see the DPL
+delegation). All of the Policy team members do basically the same
+work: shepherd proposals, propose wording, and merge changes when
+consensus has been reached. The current delegates are:
+
++ Russ Allbery
++ Bill Allombert
++ Andrew McMillan
++ Manoj Srivastava
++ Colin Watson (cjwatson)
+
+The special tasks of Policy delegates are:
+
++ Commit access to the Git repository and uploads of the debian-policy
+ package itself, which makes them responsible for debian-policy as a
+ package in Debian and for making final decisions about when a new
+ version is released and what bits go into it.
++ Rejecting proposals. Anyone can argue against a proposal, but only
+ Policy delegates can formally reject it.
++ Counting seconds and weighing objections to proposals to determine
+ whether the proposal has sufficient support to be included.
+
+Everything else can be done by anyone, or any DD (depending on the
+outcome of the discussion about seconding). We explicitly want any
+Debian DD to review and second or object to proposals. The more
+participation, the better. Many other people are active on the Policy
+mailing list without being project delegates.
+
+Task description
+~~~~~~~~~~~~~~~~~
+
+The Debian Policy team is responsible for maintaining and coordinating
+updates to the technical Policy manuals for the project. The primary
+output of the team is the Debian Policy Manual and the assorted
+subpolicies, released as the debian-policy Debian package and also
+published at [http://www.debian.org/doc/].
+
+In addition to the main technical manual, the team currently also maintains:
+
++ [Debian Menu sub-policy]
++ [Debian Perl Policy]
++ [Debian MIME support sub-policy]
++ [Debconf Specification]
++ [Authoritative list of virtual package names ]
+
+These documents are maintained using the [Policy changes process], and
+the current state of all change proposals is tracked using the
+[debian-policy BTS].
+
+
+[Debian Menu sub-policy]: http://www.debian.org/doc/packaging-manuals/menu-policy/
+[Debian Perl Policy]: http://www.debian.org/doc/packaging-manuals/perl-policy/
+[Debian MIME support sub-policy]: http://www.debian.org/doc/packaging-manuals/mime-policy/
+[Debconf Specification]: http://www.debian.org/doc/packaging-manuals/debconf_specification.html
+[Authoritative list of virtual package names ]: http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt
+[Policy changes process]: Process.txt
+[debian-policy BTS]: http://bugs.debian.org/src:debian-policy
+
+Get involved
+~~~~~~~~~~~~~
+
+The best way to help is to review the [current open bugs], pick a bug
+that no one is currently shepherding (ask on
+[debian-policy@lists.debian.org] if you're not sure if a particular bug
+is being shepherded), and help it through the change process. This
+will involve guiding the discussion, seeking additional input
+(particularly from experts in the area being discussed), possibly
+raising the issue on other mailing lists, proposing or getting other
+people to propose specific wording changes, and writing diffs against
+the current Policy document. All of the steps of [Policy changes process]
+can be done by people other than Policy team members except
+the final acceptance steps and almost every change can be worked on
+independently, so there's a lot of opportunity for people to help.
+
+There are also some other, larger projects:
+
++ Policy is currently maintained in DebianDoc-SGML, which is no longer
+ very actively maintained and isn't a widely used or understood
+ format. The most logical replacement would be DocBook. However,
+ DocBook is a huge language with many tags and options, making it
+ rather overwhelming. We badly need someone with DocBook experience
+ to write a style guide specifying exactly which tags should be used
+ and what they should be used for so that we can limit ourselves to
+ an easy-to-understand and documented subset of the language.
++ Policy contains several appendices which are really documentation of
+ how parts of the dpkg system works rather than technical
+ Policy. Those appendices should be removed from the Policy document
+ and maintained elsewhere, probably as part of dpkg, and any Policy
+ statements in them moved into the main document. This project will
+ require reviewing the current contents of the appendices and feeding
+ the useful bits that aren't currently documented back to the dpkg
+ team as documentation patches.
++ Policy has grown organically over the years and suffers from
+ organizational issues because of it. It also doesn't make use of the
+ abilities that a current XML language might give us, such as being
+ able to extract useful portions of the document (all *must*
+ directives, for example). There has been quite a bit of discussion
+ of a new format that would allow for this, probably as part of
+ switching to DocBook, but as yet such a reorganization and reworking
+ has not been started.
+
+If you want to work on any of these projects, please mail
+[debian-policy@lists.debian.org ] for more information. We'll be happy to
+help you get started.
+
+
+[current open bugs]: http://bugs.debian.org/src:debian-policy
+[debian-policy@lists.debian.org]: mailto:debian-policy@lists.debian.org
+[Policy changes process]: Process.txt
+[debian-policy@lists.debian.org ]: mailto:debian-policy@lists.debian.org
+
+Maintenance procedures
+=======================
+
+Repository layout
+==================
+
+The Git repository used for Debian Policy has the following branches:
+
++ master:: the current accepted changes that will be in the next release
++ bug<number>-<user>:: changes addressing bug <number>, shepherded by <user>
++ rra:: old history of Russ's arch repository, now frozen
++ srivasta:: old history of Manoj's arch repository
+
+Managing a bug
+===============
+
+The process used by Policy team members to manage a bug, once there is
+proposed wording, is:
+
++ Create a bug<number>-<user> branch for the bug, where <number> is
+ the bug number in the BTS and <user> is a designator of the Policy
+ team member who is shepherding the bug.
++ Commit wording changes in that branch until consensus is
+ achieved. Do not modify debian/changelog or upgrading-checklist.html
+ during this phase. Use the BTS to track who proposed the wording and
+ who seconded it.
++ git pull master to make sure you have the latest version.
++ Once the change has been approved by enough people, git merge the
+ branch into master immediately after making the final commit adding
+ the changelog entry to minimize conflicts.
++ add the debian/changelog and upgrading-checklist.html changes, and
+ commit to master.
++ Push master out so other people may merge in their own bug branches
+ without conflicts.
++ Tag the bug as pending and remove other process tags.
++ Delete the now-merged branch.
+
+The Git commands used for this workflow are:
+ git checkout -b bug12345-rra master
+ # edit files
+ # git add files
+ git commit
+ git push origin bug12345-rra
+ # iterate until good
+ # update your local master branch
+ git checkout master
+ git pull
+ # If there are changes in master that make the branch not apply cleanly:
+ git checkout -b temp master; git merge bug12345-rra
+ # If error;
+ git reset --hard HEAD;
+ git checkout bug12345-rra; git branch -D temp
+ git merge master
+ git checkout master
+ git merge bug12345-rra
+ # edit debian/changelog and upgrading-checklist.html
+ git add debian/changelog upgrading-checklist.html
+ git commit
+ git push origin master
+ git branch -d bug12345-rra
+ git push origin :bug12345-rra
+
+
+For the debian/changelog entry, use the following format:
+ * <document>: <brief change description>
+ Wording: <author of wording>
+ Seconded: <seconder>
+ Seconded: <seconder>
+ Closes: <bug numbers>
+
+
+For example:
+ * 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
+
+
+Updating branches
+==================
+
+After commits to master have been pushed, either by you or by another
+Policy team member, you will generally want to update your working bug
+branches. The equivalent of the following commands should do that:
+
+ for i in `git show-ref --heads | awk '{print $2}'`; do
+ j=$(basename $i)
+ if [ "$j" != "master" ]; then
+ git checkout $j && git merge master
+ fi
+ done
+ git push --all origin
+
+
+assuming that you haven't packed the refs in your repository.
+
+Making a release
+=================
+
+For a final Policy release, change UNRELEASED to unstable in
+debian/changelog and update the timestamp to match the final release
+time (dch -r may be helpful for this), update the release date in
+upgrading-checklist.html, update Standards-Version in debian/control,
+and commit that change. Then do the final release build and make sure
+that it builds and installs.
+
+Then, tag the repository and push the final changes to Alioth:
+
+ git tag -s v3.8.0.0
+ git push origin
+ git push --tags origin
+
+
+replacing the version number with the version of the release, of course.
+
+Finally, announce the new Policy release on debian-devel-announce,
+including in the announcement the upgrading-checklist section for the
+new release.
+
+Setting release goals
+======================
+
+Policy has a large bug backlog, and each bug against Policy tends to
+take considerable time and discussion to resolve. I've found it
+useful, when trying to find a place to start, to pick a manageable set
+of bugs and set as a target resolving them completely before the next
+Policy release. Resolving a bug means one of the following:
+
++ Proposing new language to address the bug that's seconded and approved by
+ the readers of the Policy list following the [Policy changes process] (or
+ that's accepted by one of the Policy delegates if the change isn't
+ normative; i.e., doesn't change the technical meaning of the document).
++ Determining that the bug is not relevant to Policy and closing it.
++ Determining that either there is no consensus that the bug indicates
+ a problem, that the solutions that we can currently come up with are
+ good solutions, or that Debian is ready for the change. These bugs
+ are tagged wontfix and then closed after a while. A lot of Policy
+ bugs fall into this category; just because it would be useful to
+ have a policy in some area doesn't mean that we're ready to make
+ one, and keeping the bugs open against Policy makes it difficult to
+ tell what requires work. If the problem is worth writing a policy
+ for, it will come up again later when hopefully the project
+ consensus is more mature.
+
+Anyone can pick bugs and work resolve them. The final determination to
+accept a wording change or reject a bug will be made by a Policy
+delegate, but if a patch is already written and seconded, or if a
+summary of why a bug is not ready to be acted on is already written,
+the work is much easier for the Policy delegate.
+
+One of the best ways to help out is to pick one or two bugs (checking
+on the Policy list first), say that you'll make resolving them a goal
+for the next release, and guide the discussion until the bugs can
+reach one of the resolution states above.
+
+[Policy changes process]: ./Progress.org
+
-debian-policy (3.8.3.1) UNRELEASED; urgency=low
+debian-policy (3.8.4.1) UNRELEASED; urgency=low
+
+ [ Colin Watson ]
+ * Fix path to changelog.Debian.gz in footnote on documentation symlinks.
+
+ [ Bill Allombert ]
+ * Convert upgrading-checklist to debiandoc-sgml. This generates a better
+ looking .txt file.
+ Closes: #567845
+ * Fix typo in package_upstream-version.orig.tar.gz.
+ Thanks, Salvatore Bonaccorso. (Closes: #558430)
+
+ [ Russ Allbery ]
+ * Standardize dpkg state wording and bring it in line with dpkg,
+ renaming Failed-Config to Half-Configured and use uniform
+ capitalization and punctuation. (Closes: #442134)
+
+ -- Bill Allombert <ballombe@debian.org> Fri, 21 May 2010 21:02:34 +0200
+
+debian-policy (3.8.4.0) unstable; urgency=low
[ Bill Allombert ]
* Also provide documents in single-file HTML format.
Proposed by Jari Aalto.
Closes: #544353
+ * Number the DFSG points like in the social_contract document.
+ Proposed by Enrico Zini.
+ Closes: #550192
[ Manoj Srivastava ]
* [b270d2d]: Typo fix: relayed -> related. Thanks to Matt Kraai for
Seconded: Russ Allbery
Seconded: Giacomo A. Catenazzi
Closes: #518199
-
- -- Manoj Srivastava <srivasta@debian.org> Mon, 05 Oct 2009 00:02:00 -0500
+ * [8fd91a0]
+ README Process upgrading-checklist: Created/converted to org-mode
+ Wording: Manoj Srivastava
+ Seconded: Russ Allbery
+ Closes: #545548
+ * [4da0692]: [typo-fixes]:
+ policy: Fix a number of grammatical or typographical errors
+ wording: Eric Dantan Rzewnicki
+ Seconded: Manoj Srivastava
+ * [112c4bc]: FHS Exceptions
+ policy: Explicitly allow /selinux and /sys as FHS exceptions
+ Wording: Manoj Srivastava
+ Seconded: Russ Allbery <rra@debian.org>
+ Seconded: Kurt Roeckx <kurt@roeckx.be>
+ Closes: #556972
+ This patch explicitly allows /sys and /selinux as additional
+ directories in the root file system allowed under the policy.
+ * [16afbcb]: Clarify ./debian/rules #! line
+ policy: Clarify rule for debian/rules shebang line
+ Wording: Ben Finney <ben+debian@benfinney.id.au>
+ Seconded: Kurt Roeckx <kurt@roeckx.be>
+ Seconded: Russ Allbery <rra@debian.org>
+ Seconded: Manoj Srivastava <srivasta@debian.org>
+ Explicitly state that "make -f debian/rules" and "./debian/rules"
+ must behave identically, to prevent confusion, and to promote
+ reproducibility, and conform to the principle of least surprise.
+ * [dab93b2]: Add a cron-daemon virtual package
+ policy, virtual package list: New virtual package: cron-daemon
+ wording: Javier Fernández-Sanguino Peña, Manoj Srivastava
+ Seconded: Russ Allbery <rra@debian.org>
+ Seconded: Kurt Roeckx <kurt@roeckx.be>
+ Closes: #391836
+ Create a virtual cron daemon package that:
+ - Has to provide /usr/bin/crontab and support crontab entries
+ - Correct execution of /etc/cron.d
+ - Correct support of /etc/crontab
+ - Support of crontab entries with names for days and months,
+ ranges, step values
+ - Correct execution of /etc/cron.{hourly,daily,weekly,monthly}
+
+ [ Russ Allbery ]
+ * Policy: Clarify policy on named pipes in packages
+ Wording: Russ Allbery <rra@debian.org>
+ Seconded: Manoj Srivastava <srivasta@debian.org>
+ Seconded: Andrew McMillan <andrew@morphoss.com>
+ * Change the sole occurrence of MUST to must for consistency and to
+ avoid confusion with IETF RFC keywords. Thanks, Jakub Wilk.
+ (Closes: #552757)
+
+ -- Bill Allombert <ballombe@debian.org> Wed, 27 Jan 2010 19:22:43 +0100
debian-policy (3.8.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>, Colin Watson <cjwatson@debian.org>, Bill Allombert <ballombe@debian.org>
-Standards-Version: 3.8.3
+Standards-Version: 3.8.4
Build-Depends-Indep: sgml-data (>= 2.0), debiandoc-sgml (>= 1.1.47), texlive, texlive-latex-extra, 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
date := $(shell date +"%Y-%m-%d")
version := $(shell awk -F '[()]' '/^$(package)/{ print $$2; exit }' debian/changelog)
+# either /usr/bin/emacs-snampshot or /usr/bin/emacs23
+EMACS:=$(shell if [ -x /usr/bin/emacs-snapshot ]; then \
+ echo /usr/bin/emacs-snapshot; \
+ elif [ -x /usr/bin/emacs23 ]; then \
+ echo /usr/bin/emacs23; \
+ fi)
+HAVE_ORG_EMACS:=$(strip $(EMACS))
+
+
# Location of the source dir
SRCTOP := $(CURDIR)
TMPTOP := $(SRCTOP)/debian/tmp
sanitycheck := debian/rules policy.sgml
-SGML_FILES := policy menu-policy mime-policy perl-policy
+SGML_FILES := policy menu-policy mime-policy perl-policy upgrading-checklist
DESC_FILES := debian-policy debian-menu-policy debian-perl-policy \
debian-mime-policy debconf-spec fhs
POLICY_FILES = $(SGML_FILES:=.sgml) $(SGML_FILES:=.txt.gz) \
virtual-package-names-list.txt \
- upgrading-checklist.txt libc6-migration.txt version.ent \
+ libc6-migration.txt version.ent \
debconf_spec/debconf_specification.html \
debconf_spec/debconf_specification.txt.gz \
- policy.ps.gz policy.pdf.gz
+ policy.ps.gz policy.pdf.gz README.txt README.html \
+ Process.txt Process.html
# policy.{pdf,ps,tpt,txt} are generated files
FILES_TO_CLEAN = debian/files debian/buildinfo debian/substvars \
debian/postinst debian/prerm \
- version.ent upgrading-checklist.txt \
+ version.ent \
$(SGML_FILES:=.txt.gz) $(SGML_FILES:=.html.tar.gz) \
$(SGML_FILES:=-1.html) \
policy.pdf.gz policy.ps.gz \
policy.pdf policy.ps policy.txt policy. \
body.tmp head.tmp policy.tpt
+FILES_FROM_ORG := README.txt README.html
+
STAMPS_TO_CLEAN := stamp-policy stamp-build
DIRS_TO_CLEAN := debian/tmp fhs $(SGML_FILES:=.html)
all build: stamp-build
-stamp-build: version.ent $(sanitycheck)
+stamp-build: version.ent $(sanitycheck) README.txt README.html \
+ Process.txt Process.html
$(MAKE) $(SGML_FILES:=.sgml.validate) \
$(SGML_FILES:=.html.tar.gz) \
$(SGML_FILES:=-1.html) \
$(SGML_FILES:=.txt.gz) \
policy.ps.gz policy.pdf.gz
- links -dump upgrading-checklist.html | perl -pe 's/[\r\0]//g' > \
- upgrading-checklist.txt
+ifneq (,$(strip $(HAVE_ORG_EMACS)))
+ $(MAKE) $(FILES_FROM_ORG)
+endif
$(MAKE) -C debconf_spec all
touch stamp-build
is used by, a significant number of packages, and
therefore should not be changed without peer
review. Package maintainers can then rely on this
- interfaces not changing, and the package
- management software authors need to ensure
- compatibility with these interface
- definitions. (Control file and changelog file
- formats are examples.)
+ interface not changing, and the package management
+ software authors need to ensure compatibility with
+ this interface definition. (Control file and
+ changelog file formats are examples.)
</item>
<tag>Chosen Convention</tag>
<item>
The Debian Free Software Guidelines (DFSG) form our
definition of "free software". These are:
<taglist>
- <tag>Free Redistribution
+ <tag>1. Free Redistribution
</tag>
<item>
The license of a Debian component may not restrict any
sources. The license may not require a royalty or
other fee for such sale.
</item>
- <tag>Source Code
+ <tag>2. Source Code
</tag>
<item>
The program must include source code, and must allow
distribution in source code as well as compiled form.
</item>
- <tag>Derived Works
+ <tag>3. Derived Works
</tag>
<item>
The license must allow modifications and derived
works, and must allow them to be distributed under the
same terms as the license of the original software.
</item>
- <tag>Integrity of The Author's Source Code
+ <tag>4. Integrity of The Author's Source Code
</tag>
<item>
The license may restrict source-code from being
Project encourages all authors to not restrict any
files, source or binary, from being modified.)
</item>
- <tag>No Discrimination Against Persons or Groups
+ <tag>5. No Discrimination Against Persons or Groups
</tag>
<item>
The license must not discriminate against any person
or group of persons.
</item>
- <tag>No Discrimination Against Fields of Endeavor
+ <tag>6. No Discrimination Against Fields of Endeavor
</tag>
<item>
The license must not restrict anyone from making use
used in a business, or from being used for genetic
research.
</item>
- <tag>Distribution of License
+ <tag>7. Distribution of License
</tag>
<item>
The rights attached to the program must apply to all
for execution of an additional license by those
parties.
</item>
- <tag>License Must Not Be Specific to Debian
+ <tag>8. License Must Not Be Specific to Debian
</tag>
<item>
The rights attached to the program must not depend on
rights as those that are granted in conjunction with
the Debian system.
</item>
- <tag>License Must Not Contaminate Other Software
+ <tag>9. License Must Not Contaminate Other Software
</tag>
<item>
The license must not place restrictions on other
that all other programs distributed on the same medium
must be free software.
</item>
- <tag>Example Licenses
+ <tag>10. Example Licenses
</tag>
<item>
The "GPL," "BSD," and "Artistic" licenses are examples of
<p>
It must start with the line <tt>#!/usr/bin/make -f</tt>,
so that it can be invoked by saying its name rather than
- invoking <prgn>make</prgn> explicitly.
+ invoking <prgn>make</prgn> explicitly. That is, invoking
+ either of <tt>make -f debian/rules <em>args...</em></tt>
+ or <tt>./debian/rules <em>args...</em></tt> must result in
+ identical behavior.
</p>
<p>
Since an interactive <file>debian/rules</file> script makes it
impossible to auto-compile that package and also makes it
hard for other people to reproduce the same binary
- package, all <em>required targets</em> MUST be
+ package, all <em>required targets</em> must be
non-interactive. At a minimum, required targets are the
ones called by <prgn>dpkg-buildpackage</prgn>, namely,
<em>clean</em>, <em>binary</em>, <em>binary-arch</em>,
<heading><tt>Priority</tt></heading>
<p>
- This field represents how important that it is that the user
+ This field represents how important it is that the user
have the package installed. See <ref id="priorities">.
</p>
</p>
<p>
- See <ref id="debianrules"> for information how to get the
- architecture for the build process.
+ See <ref id="debianrules"> for information on how to get
+ the architecture for the build process.
</p>
</sect1>
<p>
Thus only the first three components of the policy version
are significant in the <em>Standards-Version</em> control
- field, and so either these three components or the all
- four components may be specified.<footnote>
+ field, and so either these three components or all four
+ components may be specified.<footnote>
In the past, people specified the full version number
in the Standards-Version field, for example "2.3.0.0".
Since minor patch-level changes don't introduce new
for the most recent version should be returned first, and
entries should be separated by the representation of a
blank line (the "title" line may also be followed by the
- representation of blank line).
+ representation of a blank line).
</p>
</sect1>
no new original source archive is being distributed the
<tt>.dsc</tt> must still contain the <tt>Files</tt> field
entry for the original source archive
- <file><var>package</var>-<var>upstream-version</var>.orig.tar.gz</file>,
+ <file><var>package</var>_<var>upstream-version</var>.orig.tar.gz</file>,
but the <file>.changes</file> file should leave it out. In
this case the original source archive on the distribution
site must match exactly, byte-for-byte, the original
</example>
If this works, then the old-version is
"Installed", if not, the old version is in a
- "Failed-Config" state.
+ "Half-Configured" state.
</item>
</enumlist>
</item>
If this fails, the package is left in a
"Half-Installed" state, which requires a
reinstall. If it works, the packages is left in
- a "Config Files" state.
+ a "Config-Files" state.
</item>
<item>
Otherwise (i.e., the package was completely purged):
<var>new-postrm</var> abort-install
</example>
If the error-unwind fails, the package is in a
- "Half Installed" phase, and requires a
+ "Half-Installed" phase, and requires a
reinstall. If the error unwind works, the
package is in a not installed state.
</item>
<example compact="compact">
<var>old-preinst</var> abort-upgrade <var>new-version</var>
</example>
- If this fails, the old version is left in an
- "Half Installed" state. If it works, dpkg now
+ If this fails, the old version is left in a
+ "Half-Installed" state. If it works, dpkg now
calls:
<example compact="compact">
<var>new-postrm</var> abort-upgrade <var>old-version</var>
</example>
- If this fails, the old version is left in an
- "Half Installed" state. If it works, dpkg now
+ If this fails, the old version is left in a
+ "Half-Installed" state. If it works, dpkg now
calls:
<example compact="compact">
<var>old-postinst</var> abort-upgrade <var>new-version</var>
</example>
</p>
<p>
- If this fails, the package is in a "Failed-Config"
+ If this fails, the package is in a "Half-Configured"
state, or else it remains "Installed".
</p>
</item>
be <em>unpacked</em> the pre-dependency can be
satisfied if the depended-on package is either fully
configured, <em>or even if</em> the depended-on
- package(s) are only unpacked or half-configured,
- provided that they have been configured correctly at
- some point in the past (and not removed or partially
- removed since). In this case, both the
+ package(s) are only unpacked or in the "Half-Configured"
+ state, provided that they have been configured
+ correctly at some point in the past (and not removed
+ or partially removed since). In this case, both the
previously-configured and currently unpacked or
- half-configured versions must satisfy any version
+ "Half-Configured" versions must satisfy any version
clause in the <tt>Pre-Depends</tt> field.
</p>
<p>
A package will not be regarded as causing breakage merely
because its configuration files are still installed; it must
- be at least half-installed.
+ be at least "Half-Installed".
</p>
<p>
<p>
A package will not cause a conflict merely because its
configuration files are still installed; it must be at least
- half-installed.
+ "Half-Installed".
</p>
<p>
</p>
<p>
- If you are creating a udeb for use in the Debian Installer, you
- will need to specify that <prgn>dpkg-shlibdeps</prgn> should use
- the dependency line of type <tt>udeb</tt> by adding
- <tt>-tudeb</tt> as option<footnote>
+ If you are creating a udeb for use in the Debian Installer,
+ you will need to specify that <prgn>dpkg-shlibdeps</prgn>
+ should use the dependency line of type <tt>udeb</tt> by
+ adding the <tt>-tudeb</tt> option<footnote>
<prgn>dh_shlibdeps</prgn> from the <tt>debhelper</tt> suite
will automatically add this option if it knows it is
processing a udeb.
symlinked there, is relaxed to a recommendation.
</p>
</item>
+ <item>
+ <p>
+ The following directories in the root filesystem are
+ additionally allowed: <file>/sys</file> and
+ <file>/selinux</file>. <footnote>These directories
+ are used as mount points to mount virtual filesystems
+ to get access to kernel information.</footnote>
+ </p>
+ </item>
</enumlist>
</p>
</p>
<p>
- Note, that this applies only to directories <em>below</em>
- <file>/usr/local</file>, not <em>in</em> <file>/usr/local</file>.
- Packages must not create sub-directories in the directory
- <file>/usr/local</file> itself, except those listed in FHS,
- section 4.5. However, you may create directories below
- them as you wish. You must not remove any of the
- directories listed in 4.5, even if you created them.
+ Note that this applies only to
+ directories <em>below</em> <file>/usr/local</file>,
+ not <em>in</em> <file>/usr/local</file>. Packages must
+ not create sub-directories in the
+ directory <file>/usr/local</file> itself, except those
+ listed in FHS, section 4.5. However, you may create
+ directories below them as you wish. You must not remove
+ any of the directories listed in 4.5, even if you created
+ them.
</p>
<p>
<sect1>
<heading>The system-wide mail directory</heading>
<p>
- The system-wide mail directory is <file>/var/mail</file>. This
- directory is part of the base system and should not owned
- by any particular mail agents. The use of the old
+ The system-wide mail directory
+ is <file>/var/mail</file>. This directory is part of the
+ base system and should not be owned by any particular mail
+ agents. The use of the old
location <file>/var/spool/mail</file> is deprecated, even
though the spool may still be physically located there.
</p>
<prgn>anacron</prgn>. Thus, you should only use this
directory for jobs which may be skipped if the system is not
running.)</p>
+ <p>
+ Unlike <file>crontab</file> files described in the IEEE Std
+ 1003.1-2008 (POSIX.1) available from
+ <url id="http://www.opengroup.org/onlinepubs/9699919799/"
+ name="The Open Group">, the files in
+ <file>/etc/cron.d</file> and the file
+ <file>/etc/crontab</file> have seven fields; namely:
+ <enumlist>
+ <item>Minute [0,59]</item>
+ <item>Hour [0,23]</item>
+ <item>Day of the month [1,31]</item>
+ <item>Month of the year [1,12]</item>
+ <item>Day of the week ([0,6] with 0=Sunday)</item>
+ <item>Username</item>
+ <item>Command to be run</item>
+ </enumlist>
+ Ranges of numbers are allowed. Ranges are two numbers
+ separated with a hyphen. The specified range is inclusive.
+ Lists are allowed. A list is a set of numbers (or ranges)
+ separated by commas. Step values can be used in conjunction
+ with ranges.
+ </p>
<p>
- The scripts or crontab entries in these directories should
+ The scripts or <tt>crontab</tt> entries in these directories should
check if all necessary programs are installed before they
try to execute them. Otherwise, problems will arise when a
package was removed but not purged since configuration files
- are kept on the system in this situation.</p>
+ are kept on the system in this situation.
+ </p>
+
+ <p>
+ Any <tt>cron</tt> daemon must provide
+ <file>/usr/bin/crontab</file> and support normal
+ <tt>crontab</tt> entries as specified in POSIX. The daemon
+ must also support names for days and months, ranges, and
+ step values. It has to support <file>/etc/crontab</file>,
+ and correctly execute the scripts in
+ <file>/etc/cron.d</file>. The daemon must also correctly
+ execute scripts in
+ <file>/etc/cron.{hourly,daily,weekly,monthly}</file>.
+ </p>
</sect>
<sect id="menus">
<heading>Device files</heading>
<p>
- Packages must not include device files in the package file
- tree.
+ Packages must not include device files or named pipes in the
+ package file tree.
</p>
<p>
<file>/dev/cu*</file> devices should be changed to use
<file>/dev/ttyS*</file>.
</p>
+
+ <p>
+ Named pipes needed by the package must be created in
+ the <prgn>postinst</prgn> script<footnote>
+ It's better to use <prgn>mkfifo</prgn> rather
+ than <prgn>mknod</prgn> to create named pipes so that
+ automated checks for packages incorrectly creating device
+ files with <prgn>mknod</prgn> won't have false positives.
+ </footnote> and removed in
+ the <prgn>prerm</prgn> or <prgn>postrm</prgn> script as
+ appropriate.
+ </p>
</sect>
<sect id="config-files">
<p>
Customization of programs' X resources may also be
supported with the provision of a file with the same name
- as that of the package placed in the
- <file>/etc/X11/Xresources/</file> directory, which must
- registered as a <tt>conffile</tt> or handled as a
+ as that of the package placed in
+ the <file>/etc/X11/Xresources/</file> directory, which
+ must be registered as a <tt>conffile</tt> or handled as a
configuration file.<footnote>
Note that this mechanism is not the same as using
app-defaults; app-defaults are tied to the client
<p>
Please note that this does not override the section on
changelog files below, so the file
- <file>/usr/share/<var>package</var>/changelog.Debian.gz</file>
+ <file>/usr/share/doc/<var>package</var>/changelog.Debian.gz</file>
must refer to the changelog for the current version of
<var>package</var> in question. In practice, this means
that the sources of the target and the destination of the
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
-<html>
- <head>
- <!-- -*- Mode: Sgml -*-
- -->
-
-
- <title>Policy checklist for upgrading your packages</title>
- </head>
- <body>
-
- <h1>Policy checklist for upgrading your packages</h1>
-
- <h2>About the checklist</h2>
-
-<p>
-The checklist below has been created to simplify the upgrading process
-of old packages. Note that this list is not `official'; it simply
-gives an indication of what has changed and whether you are likely to
-need to make changes to your package in light of this. If you have
-doubts about a certain topic, if you need more details, or if you
-think some other package does not comply with policy, please refer to
-the Policy Manual itself. All of the changes from version 3.0.0
-onwards indicate which section of the Policy Manual discusses the
-issue: [3.4] means section 3.4. The section numbering changed when
-the packaging manual was incorporated into policy; the section numbers
-used below refer to the current version.
-</p>
-
-<p>
-Here is how the check list works: Check which policy version your
-package complies with currently (indicated in the "Standards-Version"
-field of the source package). Then move upwards until the top and
-check which of the items on the list might concern your package. Note
-which sections of policy discuss this, and then check out the Policy
-Manual for details. If you are upgrading from Policy version < 2.5.0,
-it may be easier to check through the whole of policy instead of
-picking your way through this list.
-</p>
-
-<h2>The checklist</h2>
-
-<pre>
-3.8.3.0 Aug 2009
-
- * Add DEB_*_ARCH_CPU and DEB_*_ARCH_OS variables and recommend them
- over GNU-style variables for that information. [4.9]
- * Source package Architecture fields may contain "all" in combination
- with other architectures. Clarify when "all" and "any" may be used
- in different versions of the field. [5.6.8]
- * The Debian archive software does not support uploading to multiple
- distributions with one *.changes file. [5.6.14]
- * The Binary field may span multiple lines. [5.6.19]
- * Remove the permission for shared library packages to install
- libraries in a non-standard location and modify ld.so.conf.
- Packages should either be installed in a standard library directory
- or packages using them should be built with RPATH. [10.2]
- * Clarify installation directories for X programs and remove the
- requirement to pre-depend on x11-common before installing into
- /usr/include/X11 and /usr/lib/X11. [11.8.7]
- * Remove the requirement that all characters in a manual page be
- representable in the legacy encoding for that language. [12.1]
- * Localized man pages should either be kept up-to-date with the
- original version or warn that they're not up-to-date, either with
- warning text or by showing missing or changed portions in the
- original language. [12.1]
- * install-info is now handled via triggers so packages no longer need
- to invoke it in maintainer scripts. Info documents should now have
- directory sections and entries in the document. Packages
- containing info documents should add a dependency to support
- partial upgrades. [12.2]
- * The requirement for Perl modules to have a versioned Depend and
- Build-Depend on perl >= 5.6.0-16 has been removed. [perl]
-
-3.8.2.0 Jun 2009
-
- * The list of archive sections has been significantly expanded. See
- http://lists.debian.org/debian-devel-announce/2009/03/msg00010.html
- for the list of new sections and rules for how to categorize
- packages. [2.4]
- * All packages must use debconf or equivalent for user prompting,
- though essential packages or their dependencies may also fall
- back on other methods. [3.9.1]
- * The requirements for source package names are now explicitly
- spelled out. [5.6.1]
- * Legacy XFree86 servers no longer get a special exception from the
- FHS permitting /etc/X11/XF86Config-4. [9.1]
- * Removed obsolete dependency requirements for packages that use
- /var/mail. [9.1.3]
- * Speedo fonts are now deprecated. The X backend was disabled
- starting in lenny. [11.8.5]
- * The GNU Free Documentation License version 1.3 is included in
- common-licenses and should be referenced from there. [12.5]
-
-3.8.1.0 Mar 2009
-
- * 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
- system is now defined by priority. [2.4, 3.7]
- * If dpkg-source -x doesn't provide the source that will be compiled,
- a debian/rules patch target is recommended and should do whatever
- else is necessary. [4.9]
- * Standardized the format of DEB_BUILD_OPTIONS. Specified permitted
- characters for tags, required that tags be whitespace-separated,
- allowed packages to assume non-conflicting tags, and required
- unknown flags be ignored. [4.9.1, 10.1]
- * 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 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
- building with dpkg-buildpackage, packages should include a
- debian/README.source file explaining how to generate the patched
- source, add a new modification, and remove an existing
- modification. This file may also be used to document packaging a
- 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
- indicating a significant difference in the language. All
- characters in the manual page source should be representable in the
- legacy encoding for a locale even if the man page is encoded in
- UTF-8. [12.1]
- * The Apache 2.0 license is now in common-licenses and should be
- referenced rather than quoted in debian/copyright. [12.5]
- * 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
-
- * Package version numbers may contain tildes, which sort before
- anything, even the end of a part. [5.6.12]
- * Scripts may assume that /bin/sh supports local (at a basic level)
- and that its test builtin (if any) supports -a and -o binary
- logical operators. [10.4]
- * The substitution variable ${binary:Version} should be used in place
- of ${Source-Version} for dependencies between packages of the same
- library. [8.5]
- * Substantial reorganization and renaming of sections in the Debian
- menu structure. Packages with menu entries should be reviewed to
- see if the menu section has been renamed or if one of the new
- sections would be more appropriate. [menu policy]
- * The Source field in a .changes file may contain a version number
- in parentheses. [5.6.1]
- * The acceptable values for the Urgency field are low, medium, high,
- critical, or emergency. [5.6.17]
- * The shlibs file now allows an optional type field, indicating the
- type of package for which the line is valid. The only currently
- supported type is udeb, used with packages for the Debian
- Installer. [8.6]
- * Packages following the Debian Configuration management
- specification must allow for translation of their messages by using
- a gettext-based system such as po-debconf. [3.9.1]
- * GFDL 1.2, GPL 3, and LGPL 3 are now in common-licenses and should
- be referenced rather than quoted in debian/copyright. [12.5]
-
-3.7.2.2 Oct 2006
-
- * Maintainer scripts must not be world writeable (up from a
- should to a must) [6.1]
-
-3.7.2.0 Apr 2006
-
- * Revert the cgi-lib change. [11.5]
-
-3.7.1.0 Apr 2006
-
- * It is now possible to create shared libraries without
- relocatable code (using -fPIC) in certain exceptional cases,
- provided some procedures are followed, and for creating static
- libraries with relocatable code (again, using -fPIC).
- Discussion on debian-devel@lists.debian.org, getting a rough
- consensus, and documenting it in README.Debian constitute most
- of the process. [10.2]
- * Packages should install any relevant files into the directories
- /usr/include/X11/and /usr/lib/X11/, but if they do so, they
- must pre-depend on x11-common (>= 1:7.0.0) [11.8.7]
-
-3.7.0.0 Apr 2006
-
- * Packages shipping web server CGI files are expected to install
- them in /usr/lib/cgi-lib/ directories. This location change
- perhaps should be documented in NEWS [11.5]
- * Web server packages should include a standard scriptAlias of
- cgi-lib to /usr/lib/cgi-lib. [11.5]
- * The version of FHS mandated by policy has been upped to
- 2.3. There should be no changes required for most packages,
- though new top level directories /media, /srv, etc may be of
- interest. [9.1.1]
- * All fields, apart from the Uploaders field, in the control file
- are supposed to be a single logical line, which may be spread
- over multiple physical lines (newline followed by space is
- elided). However, any parser for the control file must allow
- the Uploaders field to be spread over multiple physical lines
- as well, to prepare for future changes. [ 5.1, 5.6.3 ]
- * When scripts are installed into a directory in the system
- PATH, the script name should not include an extension that
- denotes the scripting language currently used to implement it.
- [ 10.4 ]
- * packages that invoke initscripts now must use invoke-rc.d to do
- so since it also pays attention to run levels and other local
- constraints. [ 9.3.3.2 ]
- * We no longer use /usr/X11R6, since we have migrated away to
- using Xorg paths. This means, for one thing, fonts live in
- /usr/share/fonts/X11/ now, and /usr/X11R6 is gone.
- [ 11.8.5.2, 11.8.7, etc]
-
-3.6.2.0 2005
-
- * Recommend doc-base, and not menu, for registering package documentation.
- * Run time support programs should live in subdirectories of
- /usr/lib/ or /usr/share, and preferably the shared lib is named
- the same as the package name (to avoid name collisions). [8.1]
- * It is recommended that HTTP servers provide an alias /images to
- allow packages to share image files with the web server [11.5]
-
-3.6.1.0 Aug 2003
-
- + Prompting the user should be done using debconf. Non debconf
- user prompts are now deprecated. [3.10.1]
-
-3.6.0 Jul 2003
-
- - Restructuring causing shifts in section numbers and bumping of
- the minor version number:
- + Many packaging manual appendices that were integrated into policy
- sections are now empty, and replaced with links to the Policy.
- In particular, the appendices that included the list of control
- fields were updated (new fields like Closes, Changed-By were added)
- and the list of fields for each of control, .changes and .dsc files
- is now in Policy, and they're marked mandatory, recommended or
- optional based on the current practice and the behavior of the
- deb-building tool-chain.
- + Elimination of needlessly deep section levels, primarily in the
- chapter Debian Archive, from which two new chapters were split out,
- Binary packages and Source packages. What remained was reordered
- properly, that is, some sect1s became sects etc.
- + Several sections that were redundant, crufty or simply not designed
- with any sort of vision, were rearranged according to the formula that
- everything should be either in the same place or properly interlinked.
- Some things remained split up between different chapters when they
- talked about different aspects of files: their content, their syntax,
- and their placement in the file system. In particular, see the new
- sections about changelog files.
- - Added Games/Simulation and Apps/Education to menu sub-policy
- [menu policy]
- - Debian changelogs should be UTF-8 encoded. [C.2.2]
- - shared libraries must be linked against all libraries that they
- use symbols from in the same way that binaries are. [10.2]
- - build-depends-indep need not be satisfied during clean
- target. [7.6]
-
-3.5.10 May 2003
-
- - packages providing the x-terminal-emulator virtual package
- ought to ensure that they interpret the command line exactly
- like xterm does. [11.8.3]
- - Window managers compliant with the Window Manager Specification
- Project may add 40 points for ranking in the alternatives [11.8.4]
-
-3.5.9.0 Mar 2003
-
- - The section describing the Description: package field once again has
- full details of the long description format. [3.4.2]
- - Clarified that if a package has non-build-essential
- build-dependencies, it should have them listed in the Build-Depends
- and related fields (i.e. it's not merely optional). [4.2]
- - When asked to restart a service that isn't already running,
- the init script should start the service. [9.3.2]
- - If the purpose of a package is to provide examples, then the
- example files can be installed into <tt>/usr/share/doc/package</tt>
- (rather than <tt>/usr/share/doc/package/examples</tt>). [12.6]
-
-3.5.8.0 Nov 2002
-
- - It is no longer necessary to keep a log of changes to the upstream
- sources in the copyright file. Instead, all such changes should be
- documented in the changelog file. [12.7]
- - <tt>Build-Depends</tt>, <tt>Build-Conflicts</tt>,
- <tt>Build-Depends-Indep</tt>, and
- <tt>Build-Conflicts-Indep</tt> must also be satisfied when the
- clean target is called. [7.6]
- - A new Apps/Science menu section is available [menu policy]
- - debconf specification cleared up, various changes. [debconf
- policy]
- - It is no longer recommended to create symlinks from nonexistent
- manual pages to undocumented(7). Missing manual pages for programs
- are still a bug. [12.1]
-
-3.5.7.0 Aug 2002
-
- - Packages no longer have to ask permission to call MAKEDEV in
- postinst, merely notifying the user ought to be enough. [10.6]
- - cryptographic software may now be included in the main
- archive. [2.2.4]
- - task packages are no longer permitted; tasks are now created by a
- special Tasks: field in the control file. [3.9]
- - window managers that support netwm can now add 20 points when
- they add themselves as an alternative for
- /usr/bin/x-window-manager [11.8.4]
- - The default compilation options have now changed, one should
- provide debugging symbols in all cases, and optionally step
- back optimization to -O0, depending on the DEB_BUILD_OPTIONS
- environment variable. [10.1]
- - Added mention of build-arch, build-indep, etc, in describing
- the relationships with `Build-Depends', `Build-Conflicts',
- `Build-Depends-Indep', and `Build-Conflicts-Indep'. May need to
- review the new rules. [7.6, 4.8]
- - Changed rules on how, and when, to invoke ldconfig in maintainer
- scripts. Long rationale. [8]
- - [Added the last note in 3.5.6 upgrading checklist item regarding
- build rules, please see below]
-
-3.5.6.0 Jul 2001
-
- - Emacs and TeX are no longer mandated by policy to be priority
- standard packages [2.5]
- - Programs that access docs need to do so via /usr/share/doc, and
- not via /usr/doc/ as was the policy previously [11.5]
- - Putting documentation in /usr/doc versus /usr/share/doc is now
- a ``serious'' policy violation. [12.3]
- - For web servers, one should not provide non-local access to the
- /usr/share/doc hierarchy. If one can't provide access controls for
- the http://localhost/doc/ directory, then it is preferred that one
- ask permission to expose that information during the install. [11.5]
- - There are new rules for build-indep/build-arch targets and
- there is a new Build-Depend-Indep semantic. [7]
-
-3.5.5.0 May 2001
-
- - Manpages should not rely on header information to have
- alternative manpage names available; it should only use
- symlinks or .so pages to do this [12.1]
- - [Clarified note in 3.5.3.0 upgrading checklist regarding
- examples and templates: this refers only to those examples used
- by scripts; see section 10.7.3 for the whole story]
- - Included a new section 10.9.1 describing the use of
- dpkg-statoverride; this does not have the weight of policy
- - Clarify Standards-Version: you don't need to rebuild your
- packages just to change the Standards-Version!
- - Plugins are no longer bound by all the rules of shared
- libraries [10.2]
- - X Windows related things:
- * Clarification of priority levels of X Window System related
- packages [11.8.1]
- * Rules for defining x-terminal-emulator improved [11.8.3]
- * X Font policy rewritten: you must read this if you provide
- fonts for the X Window System [11.8.5]
- * Packages must not ship /usr/X11R6/lib/X11/app-defaults/ [11.8.6]
- * X-related packages should usually use the regular FHS
- locations; imake-using packages are exempted from this [11.8.7]
- * OpenMotif linked binaries have the same rules as
- OSF/Motif-linked ones [11.8.8]
-
-3.5.4.0 Apr 2001
-
- - The system-wide mail directory is now /var/mail, no longer
- /var/spool/mail. Any packages accessing the mail spool should
- access it via /var/mail and include a suitable Depends field;
- details in [11.6]
- - The perl policy is now part of Debian policy proper. Perl
- programs and modules should follow the current Perl policy
- [11.9; perl-policy]
-
-3.5.3.0 Apr 2001
-
- - Build-Depends arch syntax has been changed to be less
- ambiguous. This should not affect any current packages [7.1]
- - Examples and templates files for use by scripts should now live
- in /usr/share/<package> or /usr/lib/<package>, with
- symbolic links from /usr/share/doc/<package>/examples as
- needed [10.7.3]
-
-3.5.2.0 Feb 2001
-
- - X app-defaults directory has moved from
- /usr/X11R6/lib/X11/app-defaults to /etc/X11/app-defaults [11.8.6]
-
-3.5.1.0 Feb 2001
-
- - dpkg-shlibdeps now uses objdump, so shared libraries have to be
- run through dpkg-shlibdeps as well as executables [8.1]
-
-3.5.0.0 Jan 2001
-
- - Font packages for the X Window System must now declare a
- dependency on xutils (>= 4.0.2) [11.8.5]
-
-3.2.1.1 Jan 2001
-
- - Daemon startup scripts in /etc/init.d/ should not contain
- modifiable parameters; these should be moved to a file in
- /etc/default/; see [9.3.2] for details
- - Files in /usr/share/doc must not be referenced by any
- program. If such files are needed, they must be placed in
- /usr/share/<package>/, and symbolic links created as required
- in /usr/share/doc/<package>/ [12.3]
- - Much of the packaging manual has now been imported into the
- policy document
-
-3.2.1.0 Aug 00
-
- - A package of priority standard or higher may provide two
- binaries, one compiled with support for the X Window System,
- and the other without [11.8.1]
-
-3.2.0.0 Aug 00
-
- - By default executables should not be built with the debugging
- option -g. Instead, it is recommended to support building the
- package with debugging information optionally. Details in [10.1]
- - Policy for packages where the upstream uses HTML changelog
- files has been expanded. In short, a plain text changelog file
- should always be generated for the upstream changes [12.8]
- - Please note that the new release of the X window system (3.2)
- shall probably need sweeping changes in policy
- - Policy for packages providing the following X-based features
- has been codified:
- - X server (virtual package xserver) [11.8.2]
- - X terminal emulator (virtual package x-terminal-emulator) [11.8.3]
- - X window manager (virtual package x-window-manager, and
- /usr/bin/x-window-manager alternative, with priority
- calculation guidelines) [11.8.4]
- - X fonts (this section has been written from scratch) [12.8.5]
- - X application defaults [11.8.6]
- - Policy for packages using the X Window System and FHS issues
- has been clarified; see [11.8.7]
- - No package may contain or make hard links to conffiles [11.7.3]
- - Noted that newer dpkg versions do not require extreme care in
- always creating the shared lib before the symlink, so the unpack
- order be correct [8]
-
-3.1.1.0 Nov 1999
-
- - Correction to semantics of architecture lists in Build-Depends
- etc. Should not affect many packages [7.1]
-
-3.1.0.0 Oct 1999
-
- - /usr/doc/<package> has to be a symlink pointing to
- /usr/share/doc/<package>, to be maintained by postinst
- and prerm scripts. Details are in [defunct]
- - Introduced source dependencies (Build-Depends, etc.) [7.1, 7.6]
- - /etc/rc.boot has been deprecated in favour of /etc/rcS.d.
- (Packages should not be touching this directory, but should use
- update-rc.d instead) [9.3.4]
- - update-rc.d is now the *only* allowable way of accessing the
- /etc/rc?.d/[SK]??* links. Any scripts which manipulate them
- directly must be changed to use update-rc.d instead. (This is
- because the file-rc package handles this information in an
- incompatible way.) [9.3.3]
- - Architecture-specific examples go in /usr/lib/<package>/examples
- with symlinks from /usr/share/doc/<package>/examples/* or from
- /usr/share/doc/<package>/examples itself [12.7]
- - Updated FHS to a 2.1 draft; this reverts /var/state to
- /var/lib [9.1.1]
- - Added MIME sub-policy document [9.7; mime-policy]
- - VISUAL is allowed as a (higher priority) alternative to EDITOR [12.4]
- - Modified liblockfile description, which affects
- mailbox-accessing programs. Please see the policy document for
- details [11.6]
- - If a package provides a changelog in HTML format, a text-only
- version should also be included. (Such a version may be prepared
- using lynx -dump -nolist.) [12.7]
- - Description of how to handle version numbers based on dates
- added [3.2.1]
-
-3.0.1.0 Jul 1999
-
- - Added the clarification that the .la files are essential for the
- packages using libtool's libltdl library, in which case the
- .la files must go in the run-time library package [10.2]
-
-3.0.0.0 Jun 1999
-
- - Debian formally moves from the FSSTND to the FHS. This is a
- major change, and the implications of this move are probably
- not all known. [9.1]
- - Only 3 digits of the Standards version need be included in
- control files, though all four digits are still permitted. [4.1]
- - The location of the GPL has changed to
- /usr/share/common-licenses. This may require changing the
- copyright files to point to the correct location of the GPL and
- other major licenses [12.6]
- - Packages that use libtool to create shared libraries must
- include the .la files in the -dev packages [10.2]
- - Use logrotate to rotate log files [10.8]
- - section 5.8 has been rewritten (Programs for the X Window
- System) [now 11.8]
- - There is now an associated menu policy, in a separate document,
- that carries the full weight of Debian policy [9.6; menu-policy]
- - Programs which need to modify the files /var/run/utmp,
- /var/log/wtmp and /var/log/lastlog must be installed setgid utmp [11.3]
-
-
-** Please note that section numbers below this point may not be up to date **
-
-
-2.5.0.0 Oct 1998
-
- Policy Manual:
- - Rearranged the manual to create a new Section 4, Files
- + Section 3.3 ("Files") was moved to Section 4. The Sections
- that were Section 4 and Section 5 were moved down to become
- Section 5 and Section 6.
- + What was Section 5.5 ("Log files") is now a subsection of the
- new Section 4 ("Files"), becoming section 4.8, placed after
- "Configuration files", moving the Section 4.8 ("Permissions
- and owners") to Section 4.9. All subsections of the old
- Section 5 after 5.5 were moved down to fill in the number
- gap.
- - Modified the section about changelog files to accommodate
- upstream changelogs which were formatted as HTML/ These
- upstream changelog files should now be accessible as
- /usr/doc/package/changelog.html.gz
- + Symlinks are permissible to link the real, or upstream,
- changelog name to the Debian mandated name.
- - Clarified that HTML documentation should be present in some
- package, though not necessarily the main binary package.
- - Corrected all references to the location of the copyright
- files. The correct location is /usr/doc/package/copyright
- - Ratified the architecture specification strings to cater to the
- HURD.
-
-2.4.1.0 Apr 1998
-
- Policy Manual:
- - Updated section 3.3.5 Symbolic links:
- + symbolic links within a toplevel directory should be relative,
- symbolic links between toplevel directories should be absolute
- (cf., Policy Weekly Issue#6, topic 2)
-
- - Updated section 4.9 Games:
- + manpages for games should be installed in /usr/man/man6
- (cf., Policy Weekly Issue#6, topic 3)
-
- Packaging Manual:
- - Updated prefix of chapter 12, Shared Libraries:
- ldconfig must be called in the postinst script if the package
- installs shared libraries
- (cf., Policy Weekly Issue #6, fixes:bug#20515)
-
-2.4.0.0 Jan 1998
-
- - Updated section 3.3.4 Scripts:
- + /bin/sh may be any POSIX compatible shell
- + scripts including bashisms have to specify /bin/bash as
- interpreter
- + scripts which create files in world-writable directories
- (e.g., in /tmp) should use tempfile or mktemp for creating
- the directory
-
- - Updated section 3.3.5 Symbolic Links:
- + symbolic links referencing compressed files must have the same
- file extension as the referenced file
-
- - Updated section 3.3.6 Device files:
- + /dev/tty* serial devices should be used instead of /dev/cu*
-
- - Updated section 3.4.2 Writing the scripts [in /etc/init.d]:
- + all /etc/init.d scripts have to provide the following options:
- start, stop, restart, force-reload
- + the reload option is optional and must never stop and restart
- the service
-
- - Updated section 3.5 Cron jobs:
- + cron jobs that need to be executed more often than daily should
- be installed into /etc/cron.d
-
- - Updated section 3.7 Menus:
- + removed section about how to register HTML docs to `menu'
- (the corresponding section in 4.4, Web servers and applications,
- has been removed in policy 2.2.0.0 already, so this one was
- obsolete)
-
- - New section 3.8 Keyboard configuration:
- + details about how the backspace and delete keys should be
- handled
-
- - New section 3.9 Environment variables:
- + no program must depend on environment variables to get a
- reasonable default configuration
-
- - New section 4.6 News system configuration:
- + /etc/news/organization and /etc/news/server should be supported
- by all news servers and clients
-
- - Updated section 4.7 Programs for the X Window System:
- + programs requiring a non-free Motif library should be provided
- as foo-smotif and foo-dmotif package
- + if lesstif works reliably for such program, it should be linked
- against lesstif and not against a non-free Motif library
-
- - Updated section 4.9 Games:
- + games for X Windows have to be installed in /usr/games, just as
- non-X games
-
-2.3.0.1, 2.3.0.0 Sep 1997
-
- * new section `4.2 Daemons' including rules for
- /etc/services, /etc/protocols, /etc/rpc, and /etc/inetd.conf
-
- * updated section about `Configuration files':
- packages may not touch other packages' configuration files
-
- * MUAs and MTAs have to use liblockfile
-
-2.2.0.0 Jul 1997
-
- * added section 4.1 `Architecture specification strings':
- use
- <arch>-linux
- where <arch> is one of the following:
- i386, alpha, arm, m68k, powerpc, sparc.
-
- * detailed rules for /usr/local
-
- * user ID's
-
- * editor/pager policy
-
- * cron jobs
-
- * device files
-
- * don't install shared libraries as executable
-
- * app-defaults files may not be conffiles
-
-2.1.3.2, 2.1.3.1, 2.1.3.0 Mar 1997
-
- * two programs with different functionality must not have the
- same name
-
- * "Webstandard 3.0"
-
- * "Standard for Console Messages"
-
- * Libraries should be compiled with `-D_REENTRANT'
-
- * Libraries should be stripped with "strip --strip-unneeded"
-
-2.1.2.2, 2.1.2.1, 2.1.2.0 Nov 1996
-
- * Some changes WRT shared libraries
-
-2.1.1.0 Sep 1996
-
- * No hard links in source packages
-
- * Do not use dpkg-divert or update-alternatives without consultation
-
- * Shared libraries must be installed stripped
-
-2.1.0.0 Aug 1996
-
- * Upstream changelog must be installed too
-</pre>
-
- <hr>
-
- </body>
-</html>
-
-<!-- Keep this comment at the end of the file
-Local variables:
-mode: sgml
-sgml-indent-data: t
-sgml-live-element-indicator: t
-sgml-set-face: t
-End:
--->
--- /dev/null
+<!doctype debiandoc system>
+
+<debiandoc>
+ <book>
+ <title> Policy checklist for upgrading your packages </title>
+ <author> Bill Allombert <email/ballombe@debian.org/ </author>
+ <author> Josip Rodin </author>
+ <author> Julian Gilbey </author>
+ <author> Russ Allbery </author>
+ <author> Manoj Srivastava <email/srivasta@debian.org/
+
+<chapt> About the checklist
+<p>
+The checklist below has been created to simplify the upgrading process
+of old packages. Note that this list is not "official"; it simply
+gives an indication of what has changed and whether you are likely to
+need to make changes to your package in light of this. If you have
+doubts about a certain topic, if you need more details, or if you
+think some other package does not comply with policy, please refer to
+the Policy Manual itself. All of the changes from version 3.0.0
+onwards indicate which section of the Policy Manual discusses the
+issue: [3.4] means section 3.4. The section numbering changed when
+the packaging manual was incorporated into policy; the section numbers
+used below refer to the current version.
+<p>
+Here is how the check list works: Check which policy version your
+package was checked against last (indicated in the "Standards-Version"
+field of the source package). Then move upwards until the top and
+check which of the items on the list might concern your package. Note
+which sections of policy discuss this, and then check out the Policy
+Manual for details. If you are upgrading from Policy version < 2.5.0,
+it may be easier to check through the whole of policy instead of
+picking your way through this list.
+
+<chapt> The checklist
+
+<sect> Version 3.8.4.0
+<p>
+
+Release Jan 2010.
+
+</p><p><taglist>
+<tag>9.1.1</tag>
+ <item> An FHS exception has been granted for multiarch libraries.
+ Permitting files to instead be installed to <file>/lib/triplet</file> and
+ <file>/usr/lib/triplet</file> directories.
+ </item>
+<tag>10.6</tag>
+ <item>Explicitly state that packages may not contain named pipes and
+ should instead create them in postinst and remove them in prerm or postrm.
+ </item>
+<tag>9.1.1</tag>
+ <item><file>/sys</file> and <file>/selinux</file> directories are explicitly
+ allowed as an exception to the FHS.
+ </item>
+</taglist></p>
+
+<sect> Version 3.8.3.0
+<p>
+Released Aug 2009.
+
+</p><p><taglist>
+<tag>4.9</tag>
+ <item>Add DEB_*_ARCH_CPU and DEB_*_ARCH_OS variables and
+ recommend them over GNU-style variables for that information.
+ </item>
+<tag>5.6.8</tag>
+ <item>Source package Architecture fields may contain <em/all/ in
+ combination with other architectures. Clarify when <em/all/ and <em/any/
+ may be used in different versions of the field.
+ </item>
+<tag>5.6.14</tag>
+ <item>The Debian archive software does not support uploading
+ to multiple distributions with one <file>*.changes</file> file.
+ </item>
+<tag>5.6.19</tag>
+ <item>The Binary field may span multiple lines.
+ </item>
+<tag>10.2</tag>
+ <item>Remove the permission for shared library packages to
+ install libraries in a non-standard location and modify <file/ld.so.conf/.
+ Packages should either be installed in a standard library directory
+ or packages using them should be built with RPATH.
+ </item>
+<tag>11.8.7</tag>
+ <item>Clarify installation directories for X programs and
+ remove the requirement to pre-depend on x11-common before installing
+ into <file>/usr/include/X11</file> and <file>/usr/lib/X11</file>.
+ </item>
+<tag>12.1</tag>
+ <item>Remove the requirement that all characters in a manual
+ page be representable in the legacy encoding for that language.
+ </item>
+<tag>12.1</tag>
+ <item>Localized man pages should either be kept up-to-date with
+ the original version or warn that they're not up-to-date, either
+ with warning text or by showing missing or changed portions in the
+ original language.
+ </item>
+<tag>12.2</tag>
+ <item>install-info is now handled via triggers so packages no
+ longer need to invoke it in maintainer scripts. Info documents
+ should now have directory sections and entries in the document.
+ Packages containing info documents should add a dependency to
+ support partial upgrades.
+ </item>
+<tag>perl</tag>
+ <item>The requirement for Perl modules to have a versioned
+ Depend and Build-Depend on <tt>perl >= 5.6.0-16</tt> has been removed.
+ </item>
+</taglist></p>
+
+<sect> Version 3.8.2.0
+<p>
+
+Released Jun 2009.
+
+</p><p><taglist>
+<tag>2.4</tag>
+ <item>The list of archive sections has been significantly expanded. See
+ <url id="http://lists.debian.org/debian-devel-announce/2009/03/msg00010.html"
+ name="this debian-devel-announce message">
+ for the list of new sections and rules for how to categorize
+ packages.
+ </item>
+<tag>3.9.1</tag>
+ <item>All packages must use debconf or equivalent for user prompting,
+ though essential packages or their dependencies may also fall
+ back on other methods.
+ </item>
+<tag>5.6.1</tag>
+ <item>The requirements for source package names are now explicitly
+ spelled out.
+ </item>
+<tag>9.1</tag>
+ <item>Legacy XFree86 servers no longer get a special exception from the
+ FHS permitting <file>/etc/X11/XF86Config-4</file>.
+ </item>
+<tag>9.1.3</tag>
+ <item>Removed obsolete dependency requirements for packages that use
+ <file>/var/mail</file>.
+ </item>
+<tag>11.8.5</tag>
+ <item>Speedo fonts are now deprecated. The X backend was disabled
+ starting in lenny.
+ </item>
+<tag>12.5</tag>
+ <item>The GNU Free Documentation License version 1.3 is included in
+ common-licenses and should be referenced from there.
+ </item>
+</taglist></p>
+
+<sect> Version 3.8.1.0
+<p>
+
+Released Mar 2009.
+
+</p><p><taglist>
+<tag>3.8</tag>
+ <item>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.
+ </item>
+<tag>4.4</tag>
+ <item>Changelog files must be encoded in UTF-8.
+ </item>
+<tag>4.4</tag>
+ <item>Tighten some format requirements for changelog files from a should
+ to a must.
+ </item>
+<tag>4.4.1</tag>
+ <item>Remove alternative changelog formats. Debian only supports one
+ changelog format for the Debian Archive.
+ </item>
+<tag>4.9.1</tag>
+ <item>New nocheck option for DEB_BUILD_OPTIONS indicating any build-time
+ test suite provided by the package should not be run.
+ </item>
+<tag>5.1</tag>
+ <item>All control files must be encoded in UTF-8.
+ </item>
+<tag>5.2</tag>
+ <item>debian/control allows comment lines starting with # with no
+ preceding whitespace.
+ </item>
+<tag>9.3</tag>
+ <item>Init scripts ending in .sh are not handled specially. They are not
+ sourced and are not guaranteed to be run by <prgn>/bin/sh</prgn> regardless
+ of the #! line. This brings Policy in line with the long-standing
+ behavior of the init system in Debian.
+ </item>
+<tag>9.3.2</tag>
+ <item>The start action of an init script must exit successfully and not
+ start the daemon again if it's already running.
+ </item>
+<tag>9.3.2</tag>
+ <item><file>/var/run</file> and <file>/var/lock</file> may be mounted as
+ temporary filesystems, and init scripts must therefore create any necessary
+ subdirectories dynamically.
+ </item>
+<tag>10.4</tag>
+ <item> <file>/bin/sh</file> scripts may assume that local can take multiple
+ variable arguments and supports assignment.
+ </item>
+<tag>11.6</tag>
+ <item>User mailboxes may be mode 600 and owned by the user rather than
+ mode 660, owned by user, and group mail.
+ </item>
+</taglist></p>
+
+<sect> Version 3.8.0.0
+<p>
+
+Released Jun 2008.
+
+</p><p><taglist>
+<tag>2.4, 3.7</tag>
+<item>The base section has been removed. contrib and non-free have been
+ removed from the section list; they are only categories. The base
+ system is now defined by priority.
+<tag>4.9</tag>
+<item>If <prgn>dpkg-source -x</prgn> doesn't provide the source that will be
+ compiled, a debian/rules patch target is recommended and should do whatever
+ else is necessary.
+<tag>4.9.1, 10.1</tag>
+<item>Standardized the format of DEB_BUILD_OPTIONS. Specified permitted
+ characters for tags, required that tags be whitespace-separated,
+ allowed packages to assume non-conflicting tags, and required
+ unknown flags be ignored.
+<tag>4.9.1</tag>
+<item>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
+<tag>4.13</tag>
+<item>Debian packages should not use convenience copies of code from other
+ packages unless the included package is explicitly intended to be
+ used that way.
+<tag>4.14</tag>
+<item>If dpkg-source -x doesn't produce source ready for editing and
+ building with dpkg-buildpackage, packages should include a
+ <file>debian/README.source</file> file explaining how to generate
+ the patched source, add a new modification, and remove an existing
+ modification. This file may also be used to document packaging a
+ new upstream release and any other complexity of the Debian build
+ process.
+<tag>5.6.3</tag>
+<item>The Uploaders field in debian/control may be wrapped.
+<tag>5.6.12</tag>
+<item>An empty Debian revision is equivalent to a Debian revision of 0 in
+ a version number.
+<tag>5.6.23</tag>
+<item>New Homepage field for upstream web sites.
+<tag>6.5, 6.6, 7</tag>
+<item>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.
+<tag>8.1, 8.2</tag>
+<item>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.
+<tag>9.5</tag>
+<item>Files in <file>/etc/cron.{hourly,daily,weekly,monthly}</file> must be
+ configuration files (upgraded from should). Mention the hourly
+ directory.
+<tag>11.8.6</tag>
+<item>Packages providing <file>/etc/X11/Xresources</file> files need not
+ conflict with <tt> xbase (<< 3.3.2.3a-2)</tt>, which is
+ long-obsolete.
+<tag>12.1</tag>
+<item>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
+ indicating a significant difference in the language. All
+ characters in the manual page source should be representable in the
+ legacy encoding for a locale even if the man page is encoded in
+ UTF-8.
+<tag>12.5</tag>
+<item>The Apache 2.0 license is now in common-licenses and should be
+ referenced rather than quoted in <file>debian/copyright</file>.
+<tag>12.5</tag>
+<item>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.
+<tag>debconf</tag>
+<item>Underscore (_) is allowed in debconf template names.
+</taglist></p>
+
+<sect> Version 3.7.3.0
+<p>
+
+Released Dec 2007.
+
+</p><p><taglist>
+<tag>5.6.12</tag>
+<item>Package version numbers may contain tildes, which sort before
+ anything, even the end of a part.
+<tag>10.4</tag>
+<item>Scripts may assume that <file>/bin/sh</file> supports local (at a basic
+ level) and that its test builtin (if any) supports -a and -o binary
+ logical operators.
+<tag>8.5</tag>
+<item>The substitution variable ${binary:Version} should be used in place
+ of ${Source-Version} for dependencies between packages of the same
+ library.
+<tag>menu policy</tag>
+<item>Substantial reorganization and renaming of sections in the Debian
+ menu structure. Packages with menu entries should be reviewed to
+ see if the menu section has been renamed or if one of the new
+ sections would be more appropriate.
+<tag>5.6.1</tag>
+<item>The Source field in a .changes file may contain a version number
+ in parentheses.
+<tag>5.6.17</tag>
+<item>The acceptable values for the Urgency field are low, medium, high,
+ critical, or emergency.
+<tag>8.6</tag>
+<item>The shlibs file now allows an optional type field, indicating the
+ type of package for which the line is valid. The only currently
+ supported type is udeb, used with packages for the Debian
+ Installer.
+<tag>3.9.1</tag>
+<item>Packages following the Debian Configuration management
+ specification must allow for translation of their messages by using
+ a gettext-based system such as po-debconf.
+<tag>12.5</tag>
+<item>GFDL 1.2, GPL 3, and LGPL 3 are now in common-licenses and should
+ be referenced rather than quoted in debian/copyright.
+</taglist></p>
+
+<sect> Version 3.7.2.2
+<p>
+
+Released Oct 2006.
+
+</p><p><taglist>
+<tag>6.1</tag> <item>Maintainer scripts must not be world writeable (up from a
+ should to a must)</item>
+</taglist></p>
+
+<sect> Version 3.7.2.0
+<p>
+
+Released Apr 2006.
+
+</p><p><taglist>
+<tag>11.5</tag> <item>Revert the cgi-lib change. </item>
+</taglist></p>
+
+<sect> Version 3.7.1.0
+<p>
+
+Released Apr 2006.
+
+</p><p><taglist>
+<tag>10.2</tag>
+<item>It is now possible to create shared libraries without
+ relocatable code (using -fPIC) in certain exceptional cases,
+ provided some procedures are followed, and for creating static
+ libraries with relocatable code (again, using -fPIC).
+ Discussion on debian-devel@lists.debian.org, getting a rough
+ consensus, and documenting it in README.Debian constitute most
+ of the process.
+<tag>11.8.7</tag>
+<item>Packages should install any relevant files into the directories
+ <file>/usr/include/X11/</file> and <file>/usr/lib/X11/</file>, but if
+ they do so, they must pre-depend on <tt>x11-common (>= 1:7.0.0)</tt>
+</taglist></p>
+
+<sect> Version 3.7.0.0
+<p>
+
+Released Apr 2006.
+
+</p><p><taglist>
+<tag>11.5</tag>
+<item>Packages shipping web server CGI files are expected to install
+ them in <file>/usr/lib/cgi-lib/</file> directories. This location change
+ perhaps should be documented in NEWS
+<tag>11.5</tag>
+<item>Web server packages should include a standard scriptAlias of
+ cgi-lib to <file>/usr/lib/cgi-lib</file>.
+<tag>9.1.1</tag>
+<item>The version of FHS mandated by policy has been upped to
+ 2.3. There should be no changes required for most packages,
+ though new top level directories <file>/media</file>, <file>/srv</file>,
+ etc. may be of interest.
+<tag>5.1, 5.6.3</tag>
+<item>All fields, apart from the Uploaders field, in the control file
+ are supposed to be a single logical line, which may be spread
+ over multiple physical lines (newline followed by space is
+ elided). However, any parser for the control file must allow
+ the Uploaders field to be spread over multiple physical lines
+ as well, to prepare for future changes.
+<tag>10.4</tag>
+<item>When scripts are installed into a directory in the system
+ PATH, the script name should not include an extension that
+ denotes the scripting language currently used to implement it.
+
+<tag>9.3.3.2</tag>
+<item>packages that invoke initscripts now must use invoke-rc.d to do
+ so since it also pays attention to run levels and other local
+ constraints.
+<tag>11.8.5.2, 11.8.7, etc</tag>
+<item>We no longer use <file>/usr/X11R6</file>, since we have
+ migrated away to using Xorg paths. This means, for one thing, fonts
+ live in <file>/usr/share/fonts/X11/</file> now, and <file>/usr/X11R6</file>
+ is gone.
+</taglist></p>
+
+<sect> Version 3.6.2.0
+<p>
+
+Released 2005
+
+</p><p><taglist>
+<tag></tag>
+<item>Recommend. doc-base, and not menu, for registering package documentation.
+</item>
+<tag>8.1</tag>
+<item>Run time support programs should live in subdirectories of
+ <file>/usr/lib/</file> or <file>/usr/share</file>, and preferably the shared
+ lib is named the same as the package name (to avoid name collisions).
+</item>
+<tag>11.5</tag>
+<item>It is recommended that HTTP servers provide an alias /images to
+ allow packages to share image files with the web server
+</item>
+</taglist></p>
+
+<sect> Version 3.6.1.0
+<p>
+
+Released Aug 2003.
+
+</p><p><taglist>
+<tag>3.10.1</tag>
+<item>Prompting the user should be done using debconf. Non debconf
+ user prompts are now deprecated.
+</taglist></p>
+
+<sect> Version 3.6.0
+<p>
+
+Released Jul 2003.
+
+</p><p><taglist>
+<tag></tag>
+<item>Restructuring causing shifts in section numbers and bumping of
+ the minor version number:
+<tag></tag>
+<item>Many packaging manual appendices that were integrated into policy
+ sections are now empty, and replaced with links to the Policy.
+ In particular, the appendices that included the list of control
+ fields were updated (new fields like Closes, Changed-By were added)
+ and the list of fields for each of control, .changes and .dsc files
+ is now in Policy, and they're marked mandatory, recommended or
+ optional based on the current practice and the behavior of the
+ deb-building tool-chain.
+<tag></tag>
+<item>Elimination of needlessly deep section levels, primarily in the
+ chapter Debian Archive, from which two new chapters were split out,
+ Binary packages and Source packages. What remained was reordered
+ properly, that is, some sects became sects etc.
+<tag></tag>
+<item>Several sections that were redundant, crufty or simply not designed
+ with any sort of vision, were rearranged according to the formula that
+ everything should be either in the same place or properly interlinked.
+ Some things remained split up between different chapters when they
+ talked about different aspects of files: their content, their syntax,
+ and their placement in the file system. In particular, see the new
+ sections about changelog files.
+<tag>menu policy</tag>
+<item>Added Games/Simulation and Apps/Education to menu
+ sub-policy
+<tag>C.2.2</tag>
+<item>Debian changelogs should be UTF-8 encoded.
+<tag>10.2</tag>
+<item>shared libraries must be linked against all libraries that they
+ use symbols from in the same way that binaries are.
+<tag>7.6</tag>
+<item>build-depends-indep need not be satisfied during clean
+ target.
+</taglist></p>
+
+<sect> Version 3.5.10
+<p>
+
+Released May 2003.
+
+</p><p><taglist>
+<tag>11.8.3</tag>
+<item>packages providing the x-terminal-emulator virtual package
+ ought to ensure that they interpret the command line exactly
+ like xterm does.
+<tag>11.8.4</tag>
+<item>Window managers compliant with the Window Manager Specification
+ Project may add 40 points for ranking in the alternatives
+</taglist></p>
+
+<sect> Version 3.5.9.0
+<p>
+
+Released Mar 2003.
+
+</p><p><taglist>
+<tag>3.4.2</tag>
+<item>The section describing the Description: package field once again has
+ full details of the long description format.
+<tag>4.2</tag>
+<item>Clarified that if a package has non-build-essential
+ build-dependencies, it should have them listed in the Build-Depends
+ and related fields (i.e. it's not merely optional).
+<tag>9.3.2</tag>
+<item>When asked to restart a service that isn't already running,
+ the init script should start the service.
+<tag>12.6</tag>
+<item>If the purpose of a package is to provide examples, then the
+ example files can be installed into <file>/usr/share/doc/package</file>
+ (rather than <file>/usr/share/doc/package/examples</file>).
+</taglist></p>
+
+<sect> Version 3.5.8.0
+<p>
+
+Released Nov 2002.
+
+</p><p><taglist>
+<tag>12.7</tag>
+<item>It is no longer necessary to keep a log of changes to the upstream
+ sources in the copyright file. Instead, all such changes should be
+ documented in the changelog file.
+<tag>7.6</tag>
+<item><var/Build-Depends/, <var/Build-Conflicts/, <var/Build-Depends-Indep/,
+ and <var/Build-Conflicts-Indep/ must also be satisfied when the clean
+ target is called.
+<tag>menu policy</tag>
+<item>A new Apps/Science menu section is available
+<tag>debconf policy</tag>
+<item>debconf specification cleared up, various changes.
+<tag>12.1</tag>
+<item>It is no longer recommended to create symlinks from nonexistent
+ manual pages to undocumented(7). Missing manual pages for programs
+ are still a bug.
+</taglist></p>
+
+<sect> Version 3.5.7.0
+<p>
+
+Released Aug 2002.
+
+</p><p><taglist>
+<tag></tag>
+<item>Packages no longer have to ask permission to call MAKEDEV in
+ postinst, merely notifying the user ought to be enough.
+<tag>2.2.4</tag>
+<item>cryptographic software may now be included in the main
+ archive.
+<tag>3.9</tag>
+<item>task packages are no longer permitted; tasks are now created by a
+ special Tasks: field in the control file.
+<tag>11.8.4</tag>
+<item>window managers that support netwm can now add 20 points when
+ they add themselves as an alternative for
+ <file>/usr/bin/x-window-manager</file>
+<tag>10.1</tag>
+<item>The default compilation options have now changed, one should
+ provide debugging symbols in all cases, and optionally step
+ back optimization to -O0, depending on the DEB_BUILD_OPTIONS
+ environment variable.
+<tag>7.6, 4.8</tag>
+<item>Added mention of build-arch, build-indep, etc, in describing
+ the relationships with `Build-Depends', `Build-Conflicts',
+ `Build-Depends-Indep', and `Build-Conflicts-Indep'. May need to
+ review the new rules.
+<tag>8</tag>
+<item>Changed rules on how, and when, to invoke ldconfig in maintainer
+ scripts. Long rationale.
+</taglist></p>
+
+<p><em>
+Added the last note in 3.5.6 upgrading checklist item regarding build
+rules, please see below
+</em></p>
+
+<sect> Version 3.5.6.0
+<p>
+
+Released Jul 2001.
+
+</p><p><taglist>
+<tag>2.5</tag>
+<item>Emacs and TeX are no longer mandated by policy to be priority
+ standard packages
+<tag>11.5</tag>
+<item>Programs that access docs need to do so via <file>/usr/share/doc</file>,
+ and not via <file>/usr/doc/</file> as was the policy previously
+<tag>12.3</tag>
+<item>Putting documentation in <file>/usr/doc</file> versus
+ <file>/usr/share/doc</file> is now a ``serious'' policy violation.
+<tag>11.5</tag>
+<item>For web servers, one should not provide non-local access to the
+ <file>/usr/share/doc</file> hierarchy. If one can't provide access
+ controls for the http://localhost/doc/ directory, then it is preferred
+ that one ask permission to expose that information during the install.
+<tag>7</tag>
+<item>There are new rules for build-indep/build-arch targets and
+ there is a new Build-Depend-Indep semantic.
+</taglist></p>
+
+<sect> Version 3.5.5.0
+<p>
+
+Released May 2001.
+
+</p><p><taglist>
+<tag>12.1</tag>
+<item>Manpages should not rely on header information to have
+ alternative manpage names available; it should only use
+ symlinks or .so pages to do this
+</item>
+<tag></tag>
+<item><em> Clarified note in 3.5.3.0 upgrading checklist regarding
+ examples and templates: this refers only to those examples used
+ by scripts; see section 10.7.3 for the whole story</em>
+</item>
+<tag></tag>
+<item>Included a new section 10.9.1 describing the use of
+ dpkg-statoverride; this does not have the weight of policy
+</item>
+<tag></tag>
+<item>Clarify Standards-Version: you don't need to rebuild your
+ packages just to change the Standards-Version!
+</item>
+<tag>10.2</tag>
+<item>Plugins are no longer bound by all the rules of shared
+ libraries
+</item>
+<tag>X Windows related things:</tag>
+<item><taglist>
+ <tag>11.8.1</tag>
+ <item>Clarification of priority levels of X Window System related
+ packages
+ </item>
+ <tag>11.8.3</tag>
+ <item>Rules for defining x-terminal-emulator improved </item>
+ <tag>11.8.5</tag>
+ <item>X Font policy rewritten: you must read this if you provide
+ fonts for the X Window System
+ </item>
+ <tag>11.8.6</tag>
+ <item>Packages must not ship <file>/usr/X11R6/lib/X11/app-defaults/</file>
+ </item>
+ <tag>11.8.7</tag>
+ <item>X-related packages should usually use the regular FHS
+ locations; imake-using packages are exempted from this
+ </item>
+ <tag>11.8.8</tag>
+ <item>OpenMotif linked binaries have the same rules as
+ OSF/Motif-linked ones
+ </item>
+ </taglist></item>
+</taglist></p>
+
+<sect> Version 3.5.4.0
+<p> Released Apr 2001.
+
+</p><p><taglist>
+<tag>11.6</tag>
+<item>The system-wide mail directory is now /var/mail, no longer
+ /var/spool/mail. Any packages accessing the mail spool should
+ access it via /var/mail and include a suitable Depends field;
+ details in
+</item>
+<tag>11.9; perl-policy</tag>
+<item>The perl policy is now part of Debian policy
+ proper. Perl programs and modules should follow the current Perl
+ policy
+</item>
+</taglist></p>
+
+<sect> Version 3.5.3.0
+<p> Released Apr 2001
+
+</p><p><taglist>
+<tag>7.1</tag>
+<item>Build-Depends arch syntax has been changed to be less
+ ambiguous. This should not affect any current packages
+</item>
+<tag>10.7.3</tag>
+<item>Examples and templates files for use by scripts should now live
+ in <file>/usr/share/<package></file> or
+ <file>/usr/lib/<package></file>, with symbolic links from
+ <file>/usr/share/doc/<package>/examples</file> as needed
+</item>
+</taglist></p>
+
+<sect> Version 3.5.2.0
+
+<p> Released Feb 2001.
+
+</p><p><taglist>
+<tag>11.8.6</tag>
+<item>X app-defaults directory has moved from
+ <file>/usr/X11R6/lib/X11/app-defaults</file> to
+ <file>/etc/X11/app-defaults</file>
+</item>
+</taglist></p>
+
+<sect> Version 3.5.1.0
+
+<p> Released Feb 2001.
+
+</p><p><taglist>
+<tag>8.1</tag>
+<item>dpkg-shlibdeps now uses objdump, so shared libraries have to be
+ run through dpkg-shlibdeps as well as executables
+</item>
+</taglist></p>
+
+<sect> Version 3.5.0.0
+
+<p> Released Jan 2001.
+
+</p><p><taglist>
+<tag>11.8.5</tag>
+<item>Font packages for the X Window System must now declare a
+ dependency on xutils (>= 4.0.2)
+</item>
+</taglist></p>
+
+<sect> Version 3.2.1.1
+
+<p> Released Jan 2001.
+
+</p><p><taglist>
+<tag>9.3.2</tag>
+<item>Daemon startup scripts in <file>/etc/init.d/</file> should not contain
+ modifiable parameters; these should be moved to a file in
+ <file>/etc/default/</file>
+</item>
+<tag>12.3</tag>
+<item>Files in <file>/usr/share/doc</file> must not be referenced by any
+ program. If such files are needed, they must be placed in
+ <file>/usr/share/<package>/</file>, and symbolic links
+ created as required in <file>/usr/share/doc/<package>/</file>
+</item>
+<tag></tag>
+<item>Much of the packaging manual has now been imported into the
+ policy document
+</item>
+</taglist></p>
+
+<sect> Version 3.2.1.0
+
+<p> Released Aug 00.
+
+</p><p><taglist>
+<tag>11.8.1</tag>
+<item>A package of priority standard or higher may provide two
+ binaries, one compiled with support for the X Window System,
+ and the other without
+</item>
+</taglist></p>
+
+<sect> Version 3.2.0.0
+
+<p> Released Aug 00.
+
+</p><p><taglist>
+<tag>10.1</tag>
+<item>By default executables should not be built with the debugging
+ option -g. Instead, it is recommended to support building the
+ package with debugging information optionally. Details in
+</item>
+<tag>12.8</tag>
+<item>Policy for packages where the upstream uses HTML changelog
+ files has been expanded. In short, a plain text changelog file
+ should always be generated for the upstream changes
+</item>
+<tag></tag>
+<item>Please note that the new release of the X window system (3.2)
+ shall probably need sweeping changes in policy
+</item>
+<tag></tag>
+<item>Policy for packages providing the following X-based features
+ has been codified:
+ <taglist>
+ <tag>11.8.2</tag>
+ <item>X server (virtual package xserver) </item>
+ <tag>11.8.3</tag>
+ <item>X terminal emulator (virtual package x-terminal-emulator) </item>
+ <tag>11.8.4</tag>
+ <item>X window manager (virtual package x-window-manager, and
+ <file>/usr/bin/x-window-manager</file> alternative, with priority
+ calculation guidelines)
+ </item>
+ <tag>12.8.5</tag>
+ <item>X fonts (this section has been written from scratch) </item>
+ <tag>11.8.6</tag>
+ <item>X application defaults </item>
+ </taglist>
+</item>
+<tag>11.8.7</tag>
+<item>Policy for packages using the X Window System and FHS issues
+ has been clarified;
+</item>
+<tag>11.7.3</tag>
+<item>No package may contain or make hard links to conffiles </item>
+<tag>8</tag>
+<item>Noted that newer dpkg versions do not require extreme care in
+ always creating the shared lib before the symlink, so the unpack
+ order be correct
+</item>
+</taglist></p>
+
+<sect> Version 3.1.1.0
+
+<p> Released Nov 1999.
+
+</p><p><taglist>
+<tag>7.1</tag>
+<item>Correction to semantics of architecture lists in Build-Depends
+ etc. Should not affect many packages
+</item>
+</taglist></p>
+
+<sect> Version 3.1.0.0
+
+<p> Released Oct 1999.
+
+</p><p><taglist>
+<tag>defunct</tag>
+<item><file>/usr/doc/<package></file> has to be a symlink pointing to
+ <file>/usr/share/doc/<package></file>, to be maintained by postinst
+ and prerm scripts.
+</item>
+<tag>7.1, 7.6</tag>
+<item>Introduced source dependencies (Build-Depends, etc.) </item>
+<tag>9.3.4</tag>
+<item><file>/etc/rc.boot</file> has been deprecated in favour of
+ <file>/etc/rcS.d</file>. (Packages should not be touching this directory,
+ but should use update-rc.d instead)
+</item>
+<tag>9.3.3</tag>
+<item>update-rc.d is now the <em>only</em> allowable way of accessing the
+ <file>/etc/rc?.d/[SK]??*</file> links. Any scripts which manipulate them
+ directly must be changed to use update-rc.d instead. (This is
+ because the file-rc package handles this information in an
+ incompatible way.)
+</item>
+<tag>12.7</tag>
+<item>Architecture-specific examples go in
+ <file>/usr/lib/<package>/examples</file>
+ with symlinks from <file>/usr/share/doc/<package>/examples/*</file>
+ or from <file>/usr/share/doc/<package>/examples</file> itself
+</item>
+<tag>9.1.1</tag>
+<item>Updated FHS to a 2.1 draft; this reverts <file>/var/state</file> to
+ <file>/var/lib</file>
+</item>
+<tag>9.7; mime-policy</tag>
+<item>Added MIME sub-policy document </item>
+<tag>12.4</tag>
+<item>VISUAL is allowed as a (higher priority) alternative to EDITOR
+</item>
+<tag>11.6</tag>
+<item>Modified liblockfile description, which affects
+ mailbox-accessing programs. Please see the policy document for
+ details
+</item>
+<tag>12.7</tag>
+<item>If a package provides a changelog in HTML format, a text-only
+ version should also be included. (Such a version may be prepared
+ using <prgn>lynx -dump -nolist</prgn>.)
+</item>
+<tag>3.2.1</tag>
+<item>Description of how to handle version numbers based on dates
+ added
+</item>
+</taglist></p>
+
+<sect> Version 3.0.1.0
+
+<p> Released Jul 1999.
+
+</p><p><taglist>
+<tag>10.2</tag>
+<item>Added the clarification that the .la files are essential for
+ the packages using libtool's libltdl library, in which case the .la
+ files must go in the run-time library package
+</item>
+</taglist></p>
+
+<sect> Version 3.0.0.0
+
+<p> Released Jun 1999.
+
+</p><p><taglist>
+<tag>9.1</tag>
+<item>Debian formally moves from the FSSTND to the FHS. This is a
+ major change, and the implications of this move are probably
+ not all known.
+</item>
+<tag>4.1</tag>
+<item>Only 3 digits of the Standards version need be included in
+ control files, though all four digits are still permitted.
+</item>
+<tag>12.6</tag>
+<item>The location of the GPL has changed to
+ <file>/usr/share/common-licenses</file>. This may require changing the
+ copyright files to point to the correct location of the GPL and
+ other major licenses
+</item>
+<tag>10.2</tag>
+<item>Packages that use libtool to create shared libraries must
+ include the .la files in the -dev packages
+</item>
+<tag>10.8</tag>
+<item>Use logrotate to rotate log files
+</item>
+<tag>now 11.8</tag>
+<item>section 5.8 has been rewritten (Programs for the X Window
+ System)
+</item>
+<tag>9.6; menu-policy</tag>
+<item>There is now an associated menu policy, in a separate document,
+ that carries the full weight of Debian policy
+</item>
+<tag>11.3</tag>
+<item>Programs which need to modify the files <file>/var/run/utmp</file>,
+ <file>/var/log/wtmp</file> and <file>/var/log/lastlog</file> must be
+ installed setgid utmp
+</item>
+</taglist></p>
+<p><em>
+ Please note that section numbers below this point may not be up to date
+</em></p>
+
+<sect> Version 2.5.0.0
+
+<p> Released Oct 1998.
+
+Policy Manual:
+</p><p><list>
+<item>Rearranged the manual to create a new Section 4, Files
+ <list>
+ <item>Section 3.3 ("Files") was moved to Section 4. The Sections
+ that were Section 4 and Section 5 were moved down to become
+ Section 5 and Section 6.
+ </item>
+ <item>What was Section 5.5 ("Log files") is now a subsection of the
+ new Section 4 ("Files"), becoming section 4.8, placed after
+ "Configuration files", moving the Section 4.8 ("Permissions
+ and owners") to Section 4.9. All subsections of the old
+ Section 5 after 5.5 were moved down to fill in the number
+ gap.
+ </item>
+ </list></item>
+<item>Modified the section about changelog files to accommodate
+ upstream changelogs which were formatted as HTML. These
+ upstream changelog files should now be accessible as
+ <file>/usr/doc/package/changelog.html.gz</file>
+</item>
+<item>Symlinks are permissible to link the real, or upstream,
+ changelog name to the Debian mandated name.
+</item>
+<item>Clarified that HTML documentation should be present in some
+ package, though not necessarily the main binary package.
+ </item>
+<item>Corrected all references to the location of the copyright
+ files. The correct location is <file>/usr/doc/package/copyright</file>
+ </item>
+<item>Ratified the architecture specification strings to cater to the
+ HURD.
+ </item>
+</list></p>
+
+<sect> Version 2.4.1.0
+
+<p> Released Apr 1998.
+</p>
+<sect1> Policy Manual:
+<p><taglist>
+<tag>Updated section 3.3.5 Symbolic links:</tag>
+ <item>symbolic links within a toplevel directory should be relative,
+ symbolic links between toplevel directories should be absolute
+ (cf., Policy Weekly Issue#6, topic 2)
+ </item>
+
+<tag>Updated section 4.9 Games:</tag>
+ <item>manpages for games should be installed in <file>/usr/man/man6</file>
+ (cf., Policy Weekly Issue#6, topic 3)
+ </item>
+</taglist></p>
+
+<sect1> Packaging Manual:
+<p><list>
+<item>Updated prefix of chapter 12, Shared Libraries:
+ ldconfig must be called in the postinst script if the package
+ installs shared libraries
+ (cf., Policy Weekly Issue #6, fixes:bug#20515)
+</item>
+</list></p>
+
+<sect> Version 2.4.0.0
+
+<p> Released Jan 1998
+
+</p><p><taglist>
+<tag>Updated section 3.3.4 Scripts:</tag>
+ <item><list>
+ <item>/bin/sh may be any POSIX compatible shell
+ <item>scripts including bashisms have to specify <file>/bin/bash</file>
+ as interpreter
+ <item>scripts which create files in world-writable directories
+ (e.g., in <file>/tmp</file>) should use tempfile or mktemp for creating
+ the directory
+ </list></item>
+
+<tag>Updated section 3.3.5 Symbolic Links:</tag>
+ <item>symbolic links referencing compressed files must have the same
+ file extension as the referenced file
+ </item>
+
+<tag>Updated section 3.3.6 Device files:</tag>
+ <item><file>/dev/tty*</file> serial devices should be used instead of
+ <file>/dev/cu*</file>
+ </item>
+
+<tag>Updated section 3.4.2 Writing the scripts in <file>/etc/init.d</file>:
+ <item><list>
+ <item>all <file>/etc/init.d</file> scripts have to provide the following
+ options: start, stop, restart, force-reload
+ <item>the reload option is optional and must never stop and restart
+ the service
+ </list></item>
+
+<tag>Updated section 3.5 Cron jobs:
+ <item>cron jobs that need to be executed more often than daily should
+ be installed into <file>/etc/cron.d</file>
+ </item>
+
+<tag>Updated section 3.7 Menus:
+ <item>removed section about how to register HTML docs to `menu'
+ (the corresponding section in 4.4, Web servers and applications,
+ has been removed in policy 2.2.0.0 already, so this one was
+ obsolete)
+ </item>
+
+<tag>New section 3.8 Keyboard configuration:
+ <item>details about how the backspace and delete keys should be
+ handled
+ </item>
+
+<tag>New section 3.9 Environment variables:
+ <item>no program must depend on environment variables to get a
+ reasonable default configuration
+ </item>
+
+<tag>New section 4.6 News system configuration:
+ <item><file>/etc/news/organization</file> and <file>/etc/news/server</file>
+ should be supported by all news servers and clients
+ </item>
+
+<tag>Updated section 4.7 Programs for the X Window System:
+ <item><list>
+ <item>programs requiring a non-free Motif library should be provided
+ as foo-smotif and foo-dmotif package
+ </item>
+ <item>if lesstif works reliably for such program, it should be linked
+ against lesstif and not against a non-free Motif library
+ </item>
+ </list></item>
+
+<tag>Updated section 4.9 Games:
+ <item>games for X Windows have to be installed in <file>/usr/games</file>,
+ just as non-X games
+ </item>
+</taglist></p>
+
+<sect> Version 2.3.0.1, 2.3.0.0
+
+<p> Released Sep 1997.
+
+<p><list>
+<item>new section `4.2 Daemons' including rules for
+ <file>/etc/services</file>, <file>/etc/protocols</file>,
+ <file>/etc/rpc</file>, and <file>/etc/inetd.conf</file>
+</item>
+
+<item>updated section about `Configuration files':
+ packages may not touch other packages' configuration files
+</item>
+
+<item>MUAs and MTAs have to use liblockfile</item>
+</list></p>
+
+<sect> Version 2.2.0.0
+
+<p> Released July 1997.
+
+<p><list>
+<item>added section 4.1 `Architecture specification strings':
+ use
+ <arch>-linux
+ where <arch> is one of the following:
+ i386, alpha, arm, m68k, powerpc, sparc.
+</item>
+
+<item>detailed rules for <file>/usr/local</file></item>
+
+<item>user ID's</item>
+
+<item>editor/pager policy</item>
+
+<item>cron jobs</item>
+
+<item>device files</item>
+
+<item>don't install shared libraries as executable</item>
+
+<item>app-defaults files may not be conffiles</item>
+</list></p>
+
+<sect> Version 2.1.3.2, 2.1.3.1, 2.1.3.0
+
+<p> Released Mar 1997.
+
+<p><list>
+<item>two programs with different functionality must not have the
+ same name </item>
+
+<item>"Webstandard 3.0"</item>
+
+<item>"Standard for Console Messages"</item>
+
+<item>Libraries should be compiled with `-D_REENTRANT'</item>
+
+<item>Libraries should be stripped with <prgn>strip --strip-unneeded</prgn>
+</item>
+</list></p>
+
+<sect> Version 2.1.2.2, 2.1.2.1, 2.1.2.0
+
+<p> Released Nov 1996.
+
+<p><list>
+<item>Some changes WRT shared libraries
+</list></p>
+
+<sect> Version 2.1.1.0
+
+<p> Released Sep 1996.
+
+<p><list>
+<item>No hard links in source packages</item>
+
+<item>Do not use <prgn>dpkg-divert</prgn> or <prgn>update-alternatives</prgn>
+without consultation </item>
+
+<item>Shared libraries must be installed stripped </item>
+</list></p>
+
+<sect> Version 2.1.0.0
+
+<p> Released Aug 1996.
+
+<p><list>
+ <item>Upstream changelog must be installed too </item>
+</list></p>
+</book>
+</debiandoc>
other applications
time-daemon anything that serves as a time daemon
ups-monitor anything that is capable of controlling an UPS
+ cron-daemon Any cron daemon that correctly follows policy requirements
Documentation
-------------
Rename inetd-superserver to inet-superserver
2 Dec 2007 Added ttf-japanese-gothic
Added ttf-japanese-mincho
+
+Manoj Srivastava:
+ 21 Nov 2009 (Re)Added cron-daemon
projects / debian / debian-policy.git / commitdiff