+debian-policy (4.0.0.0) unstable; urgency=low
+
+ * [ACCEPTED 10/26/99] changelog.html.gz sanitization. closes: Bug#40934
+ * [AMENDED 07/09/1999] policy on -g, a proposal closes: Bug#43787
+ * [ACCEPTED 02/01/2000] policy for usage of "xserver"
+ alternative closes: Bug#53755
+ * [ACCEPTED 02/01/2000] additions to virtual package
+ list closes: Bug#53756
+ * [ACCEPTED 02/01/2000] policy for "x-terminal-emulator"
+ virtual package and alternative closes: Bug#53757
+ * [ACCEPTED 02/01/2000] policy for "x-window-manager"
+ virtual package and alternative closes: Bug#53758
+ * [ACCEPTED 02/01/2000] revision of X application-defaults
+ policy closes: Bug#53760
+ * [ACCEPTED 02/01/2000] revision of the Motif/LessTif
+ policy closes: Bug#53761
+ * [ACCEPTED 02/01/2000] applying the FHS to packages
+ that use X closes: Bug#53762
+ * [ACCEPTED 02/01/2000] policy for X font packages closes: Bug#53763
+ * packaging manual: Added additional clarification on dpkg
+ behaviour. closes: Bug#17369
+ * Fixed missing </chapt> tag. closes: Bug#51091
+ * Documented that the library before the symlink hack (which dependend
+ on file system specific kinks to work) is no longer required by newer
+ versions of dpkg. closes: Bug#53405
+ * Fixed typo where dpkg-genchanges was used instead of
+ dpkg-gencontrol. closes: Bug#58771
+ * [PROPOSED]: clarification needed about diversions.
+ fixed usage for dpkg-divert closes: Bug#29522
+ * We have had doc-base support for a while now. closes: Bug#15709
+ * Moved the documents into the Debian/ section, since that is where they
+ belong, really. closes: Bug#54777
+ * Added policy-process to document current procedures.
+
+ -- Manoj Srivastava <srivasta@debian.org> Fri, 17 Mar 2000 17:02:12 -0600
+
debian-policy (3.1.1.3) unstable; urgency=low
* Fixed an upgrade bug when /usr/doc happens to be a symlink, and does
# Created On : Thu Oct 29 15:23:36 1998
# Created On Node : tiamat.datasync.com
# Last Modified By : Manoj Srivastava
-# Last Modified On : Mon Feb 28 22:32:47 2000
+# Last Modified On : Fri Mar 17 17:00:35 2000
# Last Machine Used: glaurung.green-gryphon.com
-# Update Count : 5
+# Update Count : 8
# Status : Unknown, Use with caution!
# HISTORY :
# Description :
# its automatic conffile handling, and all the packages we depend of
# are already fully installed and configured.
-package_name=debian-policy
+package_name=#PACKAGE#
if [ -z "package_name" ]; then
print >&2 "Internal Error. Please report a bug."
starget_dir=$(/bin/pwd);
cd /
+ link_target="../share/doc/$package_name";
+ cd /usr/doc/;
+ if [ -d ../share/doc/ ]; then
+ cd ../share/doc/
+ ltarget=$(/bin/pwd);
+ if [ "$starget_dir" = "$ltarget" ]; then
+ link_target="../share/doc/$package_name";
+ else
+ link_target="/usr/share/doc/$package_name";
+ fi
+ else
+ link_target="/usr/share/doc/$package_name"
+ fi
+
+
# Well, make sure that we do not get tripped up by the symlink
if [ -L /usr/doc/$package_name ]; then
rm -f /usr/doc/$package_name
echo "/usr/doc/$package_name still exists"
if [ -L /usr/doc/$package_name ]; then
echo "it is a symbolic link, overwriting"
- ln -sf ../share/doc/$package_name /usr/doc/$package_name
+ ln -sf $link_target /usr/doc/$package_name
else
echo "This is an error. Aborting"
exit 1
fi
fi
# File unexists. Free to go ahead and create link
- ln -sf ../share/doc/$package_name /usr/doc/$package_name
+ ln -sf $link_target /usr/doc/$package_name
fi
fi
# Created On : Thu Oct 29 15:31:03 1998
# Created On Node : tiamat.datasync.com
# Last Modified By : Manoj Srivastava
-# Last Modified On : Thu Oct 29 15:33:43 1998
-# Last Machine Used: tiamat.datasync.com
-# Update Count : 1
+# Last Modified On : Fri Mar 17 17:10:23 2000
+# Last Machine Used: glaurung.green-gryphon.com
+# Update Count : 2
# Status : Unknown, Use with caution!
# HISTORY :
# Description :
set -e
# This is filled in by debian/rules
-PACKAGE=#PACKAGE#
+package_name=#PACKAGE#
# This script is called as the first step in removing the package from
# the system. This includes cases where the user explicitly asked for
remove)
# This package about to be removed.
:
+ if [ -L /usr/doc/$package_name ]; then
+ rm -f /usr/doc/$package_name
+ fi
# There are two sub-cases:
if test "${2+set}" = set; then
upgrade)
# Prepare to upgrade FROM THIS VERSION of this package to version $2.
:
+ if [ -L /usr/doc/$package_name ]; then
+ rm -f /usr/doc/$package_name
+ fi
;;
failed-upgrade)
exit 0;;
esac
-# FSSTND compatibility symlinks
-if [ \( "$1" = "upgrade" -o "$1" = "remove" \) \
- -a -L /usr/doc/$PACKAGE ]; then
- rm -f /usr/doc/$PACKAGE
-fi
+
if [ -x /usr/sbin/install-docs ]; then
/usr/sbin/install-docs -r $PACKAGE
## Author : Manoj Srivastava ( srivasta@tiamat.datasync.com )
## Created On : Thu Oct 29 15:35:55 1998
## Created On Node : tiamat.datasync.com
-## Last Modified By : Julian Gilbey
-## Last Modified On : Mon Dec 20 21:01:12 GMT 1999
+## Last Modified By : Manoj Srivastava
+## Last Modified On : Fri Mar 17 17:01:28 2000
## Last Machine Used: glaurung.green-gryphon.com
-## Update Count : 51
+## Update Count : 53
## Status : Unknown, Use with caution!
## HISTORY :
## Description :
upgrading-checklist.text policy.text.gz \
packaging.lout packaging.text.gz packaging.ps \
packaging.pdf.gz menu-policy.text.gz \
+ policy-process.text.gz policy-process.pdf.gz \
proposal.text.gz menu-policy.pdf.gz proposal.pdf.gz \
mime-policy.text.gz mime-policy.pdf.gz
STAMPS_TO_CLEAN = stamp-policy stamp-packaging stamp-build stamp-configure
DIRS_TO_CLEAN = debian/tmp policy.html fhs debian/tmp-packaging \
packaging.html menu-policy.html mime-policy.html \
- proposal.html
-SGML_FILES = policy packaging menu-policy mime-policy proposal
+ proposal.html policy-process.html
+SGML_FILES = policy packaging menu-policy mime-policy proposal \
+ policy-process
# Location of the source dir
SRCTOP := $(shell if [ "$$PWD" != "" ]; then echo $$PWD; else pwd; fi;)
upgrading-checklist.text libc6-migration.text \
version.ent proposal.sgml proposal.text.gz \
menu-policy.sgml menu-policy.text.gz \
- mime-policy.sgml mime-policy.text.gz
+ mime-policy.sgml mime-policy.text.gz \
+ policy-process.text.gz policy-process.sgml
BYHAND_FILES =policy.text.gz libc6-migration.text \
virtual-package-names-list.text menu-policy.text.gz \
mime-policy.text.gz
(tar cf - menu-policy.html) | (cd $(DOCDIR); tar xf -)
(tar cf - mime-policy.html) | (cd $(DOCDIR); tar xf -)
(tar cf - proposal.html) | (cd $(DOCDIR); tar xf -)
- sed -e 's/#PACKAGE#/$(package)/' debian/postinst.in > debian/postinst
- sed -e 's/#PACKAGE#/$(package)/' debian/prerm.in > debian/prerm
+ (tar cf - policy-process.html) | (cd $(DOCDIR); tar xf -)
+ sed -e 's/#PACKAGE#/$(package)/g' debian/postinst.in > debian/postinst
+ sed -e 's/#PACKAGE#/$(package)/g' debian/prerm.in > debian/prerm
$(install_program) debian/{postinst,prerm} debian/tmp/DEBIAN/
dpkg-gencontrol -pdebian-policy -Pdebian/tmp -isp
chown -R root.root debian/tmp
$(install_file) debian/copyright $(PDOCDIR)/
$(install_file) packaging-manual.desc $(PLIBDIR)/packaging-manual
(tar cf - packaging.html) | (cd $(PDOCDIR); tar xf -)
- sed -e 's/#PACKAGE#/$(ppackage)/' debian/postinst.in > debian/postinst
- sed -e 's/#PACKAGE#/$(ppackage)/' debian/prerm.in > debian/prerm
+ sed -e 's/#PACKAGE#/$(ppackage)/g' debian/postinst.in > debian/postinst
+ sed -e 's/#PACKAGE#/$(ppackage)/g' debian/prerm.in > debian/prerm
$(install_program) debian/{postinst,prerm} debian/tmp-packaging/DEBIAN/
dpkg-gencontrol -ppackaging-manual -Pdebian/tmp-packaging -isp
chown -R root.root debian/tmp-packaging
<abstract>
This manual describes the technical aspects of creating Debian
- binary and source packages. It also documents the interface
- between <prgn>dselect</prgn> and its access method scripts.
- It does not deal with the Debian Project policy requirements,
- and it assumes familiarity with <prgn>dpkg</prgn>'s functions
- from the system administrator's perspective. This
- package itself is maintained by a group of maintainers
- that have no editorial powers. At the moment, the list of
- maintainers is:
+ binary and source packages. It does not deal with the Debian
+ Project policy requirements, and it assumes familiarity with
+ <prgn>dpkg</prgn>'s functions from the system administrator's
+ perspective. This package itself is maintained by a group of
+ maintainers that have no editorial powers. At the moment, the
+ list of maintainers is:
<enumlist>
<item>
<p>Michael Alan Dorman <email>mdorman@debian.org</email></p>
the value from a <tt>.deb</tt> file if they have no other
information; a value listed in a <tt>Packages</tt> file
will always take precedence. By default
- <prgn>dpkg-genchanges</prgn> does not include the section
+ <prgn>dpkg-gencontrol</prgn> does not include the section
and priority in the control file of a binary package - use
the <tt>-isp</tt>, <tt>-is</tt> or <tt>-ip</tt> options to
achieve this effect.</p>
</p>
<p>
- If one package is to be installed, the other must be removed first -
- if the package being installed is marked as replacing (<ref
- id="replaces">) the one on the system, or the one on the system is
- marked as deselected, or both packages are marked
- <tt>Essential</tt>, then <prgn>dpkg</prgn> will
- automatically remove the package which is causing the
- conflict, otherwise it will halt the installation of the new
- package with an error.
+ If one package is to be installed, the other must be removed
+ first - if the package being installed is marked as
+ replacing (<ref id="replaces">) the one on the system, or
+ the one on the system is marked as deselected, or both
+ packages are marked <tt>Essential</tt>, then
+ <prgn>dpkg</prgn> will automatically remove the package
+ which is causing the conflict, otherwise it will halt the
+ installation of the new package with an error. This
+ mechanism specifically doesn't work when the installed
+ package is tt>Essential</tt>, but the new package is not.
</p>
<p>
supposing that a <prgn>smailwrapper</prgn> package wishes to
install a wrapper around <tt>/usr/sbin/smail</tt>:
<example>
- if [ install = "$1" ]; then
+ if [ install = "$1" -o upgrade = "$1" ]; then
dpkg-divert --package smailwrapper --add --rename \
--divert /usr/sbin/smail.real /usr/sbin/smail
fi
<tt>libgdbm.so.1.7.3</tt>. This is needed so that
<prgn>ld.so</prgn> can find the library in between the time
<prgn>dpkg</prgn> installs it and <prgn>ldconfig</prgn> is run
- in the <prgn>postinst</prgn> script. Futhermore, and <em>this
- is very important</em>, the library must be placed before the
- symlink pointing to it in the <tt>.deb</tt> file. This is so
- that by the time <prgn>dpkg</prgn> comes to install the
- symlink (overwriting the previous symlink pointing at an older
- version of the library) the new shared library is already in
- place. Currently the way to ensure the ordering is done
- properly is to install the library in the appropriate
- <tt>debian/tmp/.../lib</tt> directory before creating the
- symlink, by putting the commands in the <tt>debian/rules</tt>
- in the appropriate order. Whether this has been done
- correctly can be checked by performing an <tt>ls -f</tt>.
+ in the <prgn>postinst</prgn> script. Futhermore, older
+ versions of the package management system required the library
+ must be placed before the symlink pointing to it in the
+ <tt>.deb</tt> file. This is so that by the time
+ <prgn>dpkg</prgn> comes to install the symlink (overwriting
+ the previous symlink pointing at an older version of the
+ library) the new shared library is already in place.
+ Unfortunately, this was not not always possible, since it
+ highly depends on the behaviour of the filesystem. Some
+ filesystems (such as reisefs) will reorder the files so it
+ doesn't matter in what order you create them. In newer
+ versions of <prgn>dpkg</prgn>, this is handled automatically.
</p>
<!--
--- /dev/null
+<!doctype debiandoc public "-//DebianDoc//DTD DebianDoc//EN">
+<debiandoc>
+ <book>
+ <titlepag>
+ <title>A mechanism for updating Debian Policy documents</title>
+ <author>
+ <name>Manoj Srivastava</name>
+ <email>srivasta@debian.org</email>
+ </author>
+ <version>$Revision: 1.1 $</version>
+ <copyright>
+ <copyrightsummary>Copyright © 2000 by Manoj Srivastava.
+ </copyrightsummary>
+ <p>
+ You are given permission to redistribute this document
+ and/or modify it under the terms of the GNU General Public
+ License as published by the Free Software Foundation; either
+ version 2, or (at your option) any later version.</p>
+ <p>
+ On Debian GNU/Linux systems, the complete text of the GNU
+ General Public License can be found in
+ `<var>/usr/share/common-licenses/GPL</var>'. </p>
+ </copyright>
+ </titlepag>
+ <chapt>
+ <heading>Introduction, and Administrivia</heading>
+ <p>
+ This document documents the current practice followed in updating
+ Debian Policy documents. This mechanism has been designed for
+ dealing with policy changes that are light
+ weight and can be decided upon within the policy group, by
+ near consensus. In most day-to-day cases, the Policy group
+ should and must be able to conduct Policy discussions and
+ amendments without the intervention of the Technical Committee
+ or other Constitutional issues. Only in cases of extreme
+ dispute (formal objections) should the intervention of
+ Constitutional bodies come into play. In any other situation,
+ the Policy group should be able to conduct business
+ unfettered. A consequence of this goal is that formal
+ objections should not be used lightly, else this mechanism
+ shall be ineffective.
+ </p>
+ <p>
+ It should be noted that the team responsible for the task of
+ updating policy does not act as author or editor of Policy
+ itself, that is the task of the Debian Policy mailing list.
+ </p>
+ <p>
+ <em>In the following, the term developer refers to registered
+ Debian developers.</em>
+ </p>
+ <p>A copy of this document should also be found at <url
+ id="http://master.debian.org/%7Esrivasta/policy/"></p>
+ </chapt>
+ <chapt>
+ <heading>Archives and Personnel</heading>
+ <sect>
+ <heading>The policy maintainers team</heading>
+ <p>
+ The policy document is maintained by a group of people who have
+ access to the CVS repository for the Policy documents;
+ however, this set of people behave more like maintainers
+ rather than authors/editors. This group does not create
+ policy, nor does it exercise editorial control, Policy is
+ decided "upstream". The group that decides on policy should
+ be the group of developers on the Debian-policy mailing
+ lists, which is how it was always done; so the group of
+ policy maintainers have no real power over policy.
+ </p>
+ <p>
+ Since the policy maintainers have no special powers, there
+ is no restriction of their participattion the discussion. It
+ is preferable to have atleast 4-5 people on the job,
+ perhapscloser to 8, so that policy does not languish when
+ any maintainer goes missing (we do need vacations, you know,
+ once in a while), and since little creative power is vested
+ in the maintainers, we do not need a central control. And
+ the BTS can be used as a record of the action decided upon
+ even if all maintainers are away at some time.
+ </p>
+ </sect>
+ <sect>
+ <heading>The CVS Repository</heading>
+ <p>
+ There is a repository set up on <tt>cvs.debian.org</tt> for
+ this, and the people on the policy maintainer team have
+ write access to it. The Debian policy mailing list gets
+ copies of all the CVS commit notices
+ </p>
+ </sect>
+ </chapt>
+ <chapt>
+ <heading>Procedures and Processes</heading>
+
+ <sect>
+ <heading>Initiating discussions</heading>
+ <p>
+ Unlike before, when the policy editor gathered in issues
+ which, in his view, were candidates for inclusion in policy,
+ any one can raise an issue in the mailing list. It is
+ advisable, but by no means mandatory, that the proposer
+ tries an idea out on the mailing list, which can help flesh
+ out details rapidly, and test the sentiment and the
+ collective wisdom of the list. Discussion may be intiated by
+ any member of the list.
+ </p>
+ <p>
+ Once the proposer is satisfied that the proposal has merit
+ (with or without trying the waters on the list), the
+ proposer should file a <em>wishlist</em> bug against the
+ debian-policy package. This stage can be initiated by any
+ member of the list.
+ </p>
+ </sect>
+ <sect>
+ <heading>Creating a proposal</heading>
+
+ <p>
+ Any Debian developer can create a proposal by retitling the
+ wishlist bug in the BTS to have the subject of the form
+ <strong>"[PROPOSED] ..."</strong>. (Note: The developer may
+ coalesce these steps into one by directly filing a
+ <em>wishlist</em> bug with the proper seubject format).
+ </p>
+ <p>
+ This is the pre discussion period, when the idea is kicked
+ around, and polished. There is no preset time limit, but at
+ some point, if it is stalled, the bug should be closed. A
+ suggested time period is 6 months, since if the
+ proposal has had no action in that period, it is very likely
+ dead. If six months have actually passed, the bug should be
+ retitled <strong>"[OLD PROPOSAL] ..."</strong>, and have the
+ severity set to fixed. The maintianers shall flush out old
+ proposal after a a suuficiently long period of time
+ (cetainly more than a year or so).
+ </p>
+ <p>
+ developers may second the issue by emailing "seconded"
+ to the BTS. Only registered Debian developers may
+ second proposals.
+ </p>
+ </sect>
+ <sect>
+ <heading>Creating an Amendment</heading>
+ <p>
+ When a proposal in the BTS has acquired two seconds (apart
+ from the proposer), it becomes a formal amendment. The bug
+ severity is raised to "normal" and the bug is retitled to
+ <strong>"[AMENDMENT DD/MM/YYY] ..."</strong>.
+ </p>
+ <p>
+ The rationale behind the requirement for seconders is that
+ it would<enumlist>
+ <item>
+ <p>
+ Encourage people to test the waters on the policy
+ mailing list, and this could help create an proposal
+ with a better chance of success</p>
+ </item>
+ <item>
+ <p>
+ Prevent frivolous or ill conceived proposals from
+ wasting peoples time (If the proposal does not even
+ convince two developers, surely this is not ready for
+ inclusion in Policy?)</p>
+ </item>
+ </enumlist>
+ </p>
+ <p>
+ The whole discussion process is meant to be light weight; If
+ you wish the proposals to be amended, talk to the proposer,
+ and get the amendment in. Or else, post an alternative, and
+ let the group decide which one is better.
+ </p>
+ <p>
+ If the process gets very contentious, and needs something
+ like votes on amendments and withdrawal of proposal, then
+ this is not the correct forum for this, and the procedures
+ outlined in the constitution should be followed. Note that
+ only non-technical issues can be resolved using the general
+ resolution protocol; technical issues would hopefully be
+ resolved in the group itself, or the technical committee can
+ be called upon to render a decision.
+ </p>
+ <p>
+ This document is not supposed to supplant the processes
+ outlined in the constitution, nor is it an end run around
+ them.
+ </p>
+ </sect>
+
+ <sect>
+ <heading>Final disposition of the proposal</heading>
+ <sect1>
+ <heading>An accepted amendment</heading>
+ <p>
+ if the amendment is accepted, the bug is marked
+ forwarded and retitled <strong>"[ACCEPTED DD/MM/YYY]..."</strong>.
+ </p>
+ </sect1>
+ <sect1>
+ <heading>An amendment that stalls or is rejected</heading>
+ <p>
+ if the amendment is stalls, or otherwise fails to pass, it
+ is retitled as <strong>"[REJECTED DD/MM/YYY] ..."</strong>
+ and has its severity set to <tt>fixed</tt>.
+ </p>
+ </sect1>
+ </sect>
+
+
+ <sect>
+ <heading>Deadlines for Tabling Discussions</heading>
+ <p>
+ It has been observed in the past that discussions on the
+ mailing list devolve into endless arguments. In order to get
+ away from the debating society aspect, at the time of the
+ formal proposal, a deadline can be set (probably by the
+ proposer, since they are likely to have an idea how
+ contentious the discussion is likely to be) for ending
+ discussion on the issue, which should rarely be less than 10
+ days, and typically two weeks or so. I hope that a hard
+ minimum period need not be set, and that the proposers would
+ be reasonable, and not set too short or too long a time for
+ discussion.
+ </p>
+ <p>
+ If a consensus is reached by the policy group, then the
+ maintainers shall enter the amendment into the Policy
+ document, announce the inclusion in the periodic report, and
+ release a new version.</p>
+ <sect1>
+ <heading>Extensions to Deadlines?</heading>
+ <p>
+ If a deadline is approaching, and the discussion s almost
+ concluded (in other words, it has not reached an impasse),
+ and the consensus on the policy group is that an extension
+ of a week would resolve the issues better, a one-time
+ extension could be granted. Care should be taken in
+ exercising this option, since abusing this would merely
+ postpone closures. Anything that is still not resolved is
+ too contentious not to be sent to the full set of
+ developers in a general resolution proposal.
+ </p>
+ </sect1>
+ </sect>
+ <sect>
+ <heading>Deadlock resolution</heading>
+ <p>
+ Formerly, arriving at a consensus was the only way to amend
+ Policy. That worked well when the Project was small,
+ however, we have apparently grown out of that phase, and even
+ the policy mailing list has grown more fractious than in the
+ days of yore. We now need a formal process of deadlock
+ resolution, and we need to recognize that on non-technical
+ issues a small minority should not always hold up deployment
+ of policy.</p>
+ <p>
+ If a consensus is not reached, (or if someone submits a
+ formal objection to the proposal) and the end of the
+ discussion period is near, then one is faced with a dilemma.
+ </p>
+ <sect1>
+ <heading>Impasse on Technical Issues</heading>
+ <p>
+ On technical issues, popularity is a bad way of arriving
+ at conclusions. Hopefully, the policy group would arrive
+ at a consensus on their own. If that fails to happen, or
+ if there is a formal objection raised on the issue, and
+ the issue is a technical one, then the technical committee
+ may be consulted. This should be a rare occurrence. </p>
+ </sect1>
+ <sect1>
+ <heading>Non Technical and Subjective Disagreements</heading>
+ <p>
+ However, if the issue is non-technical and subjective,
+ then a vote of the developers may be taken (USENET voting
+ software should be available all over the place, right?);
+ and a super-majority of 75% is needed to carry the
+ amendment through. Failing the super-majority, the issue
+ should be shelved. It may be re-submitted as a a fresh
+ proposal after a suitable cooling off period (which should
+ be no less than a month, typically three months being
+ desirable, unless there are significant new
+ developments). (Demote bug, if the BTS is being used)</p>
+ <p>
+ If the issue raised is especially contentious, or is
+ deemed to be suitable for review by the full set of
+ developers, then four or more developers can call for a
+ hold on the proposal, and move to send the proposal to the
+ larger developer body as a General
+ Resolution. <strong>Note:</strong> The constitution may
+ have additional requirements for submitting a General
+ Resolution, for example, a minimum number of seconders,
+ etc.
+ </p>
+ </sect1>
+ </sect>
+ </chapt>
+
+ </book>
+</debiandoc>
\ No newline at end of file
mechanisms involved in package creation, installation, and
removal. This information can be found in the <em>Debian
Packaging Manual</em> and the <em>Debian System
- Administrators' Manual</em>.
+ Administrators' Manual</em>. Please note that the
+ footnotes present in this manual are merely informative,
+ and are not part of Debian policy itself.
</p>
<p>
This document assumes familiarity with these other two
</sect>
</chapt>
<chapt>
- <heading>Files</heading>
-
+ <heading>Files</heading>
+
+
+ <sect>
+ <heading>Binaries</heading>
- <sect>
- <heading>Binaries</heading>
-
- <p>
- It is not allowed that two packages install programs with
- different functionality but with the same filenames. (The
- case of two programs having the same functionality but
- different implementations is handled via `alternatives.')
- If this case happens, one of the programs has to be
- renamed. The maintainers should report this to the
- developers' mailing and try to find a consensus about
- which package will have to be renamed. If a consensus can
- not be reached, <em>both</em> programs must be
- renamed.</p>
-
- <p>
- Generally the following compilation parameters should be used:
- <example>
- CC = gcc
- CFLAGS = -O2 -g -Wall # sane warning options vary between programs
- LDFLAGS = # none
- install -s # (or use strip on the files in debian/tmp)
- </example></p>
-
- <p>
- Note that all installed binaries should be stripped,
- either by using the <tt>-s</tt> flag to
- <prgn>install</prgn>, or by calling <prgn>strip</prgn> on
- the binaries after they have been copied into
- <tt>debian/tmp</tt> but before the tree is made into a
- package.</p>
-
- <p>
- The <tt>-g</tt> flag is useful on compilation so that you
- have available a full set of debugging symbols in your
- built source tree, in case anyone should file a bug report
- involving (for example) a core dump.</p>
-
- <p>
- The <tt>-N</tt> flag should not be used. On a.out systems
- it may have been useful for some very small binaries, but
- for ELF it has no good effect.</p>
-
- <p>
+ <p>
+ It is not allowed that two packages install programs with
+ different functionality but with the same filenames. (The
+ case of two programs having the same functionality but
+ different implementations is handled via `alternatives.')
+ If this case happens, one of the programs has to be
+ renamed. The maintainers should report this to the
+ developers' mailing and try to find a consensus about
+ which package will have to be renamed. If a consensus can
+ not be reached, <em>both</em> programs must be
+ renamed.</p>
+
+ <p>
+ Generally the following compilation parameters should be used:
+ <example>
+ CC = gcc
+ CFLAGS = -O2 -Wall # sane warning options vary between programs
+ LDFLAGS = # none
+ install -s # (or use strip on the files in debian/tmp)
+ </example></p>
+
+ <p>
+ Note that by default all installed binaries should be stripped,
+ either by using the <tt>-s</tt> flag to
+ <prgn>install</prgn>, or by calling <prgn>strip</prgn> on
+ the binaries after they have been copied into
+ <tt>debian/tmp</tt> but before the tree is made into a
+ package.</p>
+
+ <p>
+ The <tt>-N</tt> flag should not be used. On a.out systems
+ it may have been useful for some very small binaries, but
+ for ELF it has no good effect.</p>
+
+ <p>
+ Debugging symbols are useful for error diagnosis, investigation
+ of core dumps (which may be submitted by users in bug reports),
+ or testing and developing the software. Therefore it is
+ recommended to support building the package with
+ debugging information through the following interface:
+ If the environment variable <tt>DEB_BUILD_OPTIONS</tt>
+ contains the string <tt>debug</tt>, compile the software with
+ debugging information (usually this involves adding the
+ <tt>-g</tt> flag to <tt>CFLAGS</tt>). This allows to generate
+ a build tree with debugging information. If the environment
+ variable <tt>DEB_BUILD_OPTIONS</tt> contains the
+ string <tt>nostrip</tt>, do not strip the files at installation
+ time. This allows to generate a package with debugging
+ information included. The following makefile snippet
+ is only an example how to test for either
+ condition:
+ <footnote>
+ <p>
+ Rationale: Building by default with -g causes more
+ wasted CPU cycles since the information is stripped away
+ anyway. The package can by default build without -g if
+ it also provides a mechanism to easily be rebuilt with
+ debugging information. This can be done by providing a
+ "build-debug" make target, or allowing the user to
+ specify "BUILD_DEBUG=yes" in the environment while
+ compiling that package.
+ </p>
+ <p>Now this has several added benefits:
+ <list>
+ <item>
+ <p>
+ It is actually easier to build debugging bins and
+ libraries this way (no more editing debian/rules
+ or similar) since it provides a documented way of
+ getting this type of build.</p>
+ </item>
+ <item>
+ <p>
+ There will be much less wasted cpu time for the
+ autobuilders since not having debugging
+ information (and hence also not having to strip
+ it) will increase the speed of compiles. This
+ skips an entire pass of the compiler,
+ </p>
+ </item>
+ </list>
+ </p>
+ </footnote>
+
+ <example>
+ CFLAGS = -O2 -Wall
+ INSTALL = install
+
+ ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
+ CFLAGS += -g
+ ifneq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
+ INSTALL += -s
+ endif
+ endif
+ </example></p>
+
+ <p>
It is up to the package maintainer to decide what
compilation options are best for the package. Certain
binaries (such as computationally-intensive programs) may
contains X shared libraries). Users who wish to use the
program can install just the relatively small
<tt>xfree86-common</tt> and <tt>xlib6g</tt> packages, and do
- not need to install the whole of X.</p>
+ not need to install the whole of X.
+ <footnote>
+ <p>Note: With the release of the new X window System
+ version (4.X), there probably shall be a sweeping change
+ in the X Window System Policy in the future.</p>
+ </footnote>
+ </p>
<p>
Do not create two versions (one with X support and one
without) of your package.</p>
<p>
- <em>Application defaults</em> files have to be installed in
- the directory <tt>/usr/X11R6/lib/X11/app-defaults/</tt>.
- They are considered as part of the program code. Thus, they
- should not be modified and should not be tagged as
- <em>conffile</em>s nor otherwise treated as configuration
- files. If the local system administrator wants
- to customize X applications globally, a file with the same
- name as that of the package should be placed in the
- <tt>/etc/X11/Xresources/</tt> directory instead.
+ <em>Packages which provide an X server</em> that, directly or
+ indirectly, communicates with real input and display hardware
+ should declare in their control data that they provide the
+ virtual package <tt>xserver</tt>.
+ <footnote>
+ <p>
+ Rationale: implement current practice, and provide an
+ actual policy for usage of the "xserver" virtual package
+ which appears in the virtual packages list.
+ In a nutshell, X servers that interface directly with
+ the display and input hardware or via another subsystem
+ (e.g., GGI) should provide xserver. Things like Xvfb,
+ Xnest, and Xprt should not.
+ </p>
+ </footnote>
+ </p>
+
+ <p>
+ <em>Packages that provide a terminal emulator</em> for the X
+ Window System which support a terminal type with a terminfo
+ description provided in the <tt>ncurses-base</tt> package
+ should declare in their control data that they provide the
+ virtual package <tt>x-terminal-emulator</tt>. They should
+ also register themselves as an alternative for
+ <tt>/usr/bin/x-terminal-emulator</tt>, with a priority of
+ 20.
+ </p>
+
+ <p>
+ <em>Packages that provide window managers</em> should declare in
+ their control data that they provide the virtual package
+ <tt>x-window-manager</tt>. They should also register themselves as an
+ alternative for <tt>/usr/bin/x-window-manager</tt>, with a priority
+ calculated as follows:
+ <list>
+ <item>Start with a priority of 20.</item>
+ <item>If the window manager supports the Debian menu system,
+ add 20 points if this support is available in the
+ package's default configuration (i.e., no
+ configuration files belonging to the system or user
+ have to be edited to activate the feature); if
+ configuration files must be modified, add only 10
+ points.</item>
+ <item>If the window manager permits the X session to be
+ restarted using a <em>different</em> window manager
+ (without killing the X server) in its default
+ configuration, add 10 points; otherwise add
+ none.</item>
+ </list>
+ </p>
+
+ <p>
+ <em>Packages that provide fonts for the X Window System</em>
+ must do a number of things to ensure that they are both
+ available without modification of the X or font server
+ configuration, and that they do not corrupt files used by
+ other font packages to register information about themselves.
+ <enumlist>
+ <item>
+ Fonts of any type supported by the X Window System
+ should be be in a separate binary package from any
+ executables, libraries, or documentation (except that
+ specific to the fonts shipped); if a program or
+ library is <em>unusable</em> without one or more
+ specific fonts, the package containing the program or
+ library should declare a dependency on the package(s)
+ containing the font(s) it requires.
+ </item>
+ <item>
+ BDF fonts should be converted to PCF fonts with the
+ <tt>bdftopcf</tt> utility (available in the
+ <tt>xbase-clients</tt> package, <tt>gzip</tt>ped, and
+ placed in a directory that corresponds to their
+ resolution:
+ <list>
+ <item>
+ 100 dpi fonts should be placed in
+ <tt>/usr/X11R6/lib/X11/fonts/100dpi/</tt>.
+ </item>
+ <item>
+ 75 dpi fonts should be placed in
+ <tt>/usr/X11R6/lib/X11/fonts/75dpi/</tt>.
+ </item>
+ <item>
+ Character-cell fonts, cursor fonts, and other
+ low-resolution fonts should be placed in
+ <tt>/usr/X11R6/lib/X11/fonts/misc/</tt>.
+ </item>
+ </list>
+ </item>
+ <item>
+ Speedo fonts should be placed in
+ <tt>/usr/X11R6/lib/X11/fonts/Speedo/</tt>.
+ </item>
+ <item>
+ Type 1 fonts should be placed in
+ /usr/X11R6/lib/X11/fonts/Type1/</tt>. If font metric files are
+ available, they may be placed here as well.
+ </item>
+ <item>
+ Subdirectories of <tt>/usr/X11R6/lib/X11/fonts/</tt>
+ other than those listed above should be neither created nor
+ used. (The <tt>PEX</tt> and <tt>cyrillic</tt> directories are
+ excepted for historical reasons, but installation of files into
+ these directories remains discouraged.)
+ </item>
+ <item>
+ Font packages may, instead of placing files directly in
+ the X font directories listed above, provide symbolic links in
+ the font directory which point to the files' actual location
+ in the filesystem. Such a location should comply with the
+ FHS.
+ </item>
+ <item>
+ Font packages should not contain both 75dpi and 100dpi
+ versions of a font. If both are available, they should be
+ provided in separate binary packages with "-75dpi" or "-100dpi"
+ appended to the names of the packages containing the
+ corresponding fonts.
+ </item>
+ <item>
+ Fonts destined for the <tt>misc</tt> subdirectory should
+ not be included in the same package as 75dpi or 100dpi fonts;
+ instead, they should be provided in a separate package with
+ "-misc" appended to its name.
+ </item>
+ <item>
+ Font packages <em>must not</em> provide the files
+ <tt>fonts.dir</tt>, <tt>fonts.alias</tt>, or
+ <tt>fonts.scale</tt> in a font directory.
+ <list>
+ <item>
+ <tt>fonts.dir</tt> files must not be provided at
+ all.
+ </item>
+ <item>
+ <tt>fonts.alias</tt> and <tt>fonts.scale</tt>
+ files, if needed, should be provided in the
+ directory
+ <tt>/etc/X11/fonts/<em>fontdir</em>/<em>package</em>.<em>extension</em></tt>,
+ where <em>fontdir</em> is the name of the
+ subdirectory of
+ <tt>/usr/X11R6/lib/X11/fonts/</tt> where the
+ package's corresponding fonts are stored (e.g.,
+ <tt>75dpi</tt> or <tt>misc</tt>),
+ <em>package</em> is the name of the package that
+ provides these fonts, and <em>extension</em> is
+ either <tt>scale</tt> or <tt>alias</tt>,
+ whichever corresponds to the file
+ contents.
+ </item>
+ </list>
+ </item>
+ <item>
+ Font packages must declare a dependency on
+ <tt>xbase-clients</tt> and, in the package
+ post-installation and post-removal scripts, invoke the
+ <tt>mkfontdir</tt> command on each directory into
+ which they installed fonts.
+ </item>
+ <item>
+ Font packages that provide one or more
+ <tt>fonts.scale</tt> files as described above must declare a
+ versioned dependency on <tt>xbase-clients (>=
+ 3.3.3.1-5)</tt> and invoke <tt>update-fonts-scale</tt> on each
+ directory into which they installed fonts
+ <em>before</em> invoking <tt>mkfontdir</tt> on that
+ directory. This invocation must occur in both the
+ post-installation and post-removal scripts.
+ </item>
+ <item>
+ Font packages that provide one or more
+ <tt>fonts.alias</tt> files as described above must
+ declare a versioned dependency on <tt>xbase-clients
+ (>= 3.3.3.1-5)</tt> and, in the package
+ post-installation and post-removal scripts, invoke
+ <tt>update-fonts-alias</tt> on each directory into
+ which they installed fonts.
+ </item>
+ <item>
+ Font packages must not provide alias names for the
+ fonts they include which collide with alias names already in
+ use by fonts already packaged.
+ </item>
+ <item>
+ Font packages must not provide fonts with the same XLFD
+ registry name as another font already packaged.
+ </item>
+ </enumlist>
+ </p>
+
+ <p>
+ <em>Application defaults</em> files must be installed in the
+ directory <tt>/usr/X11R6/lib/X11/app-defaults/</tt>. They should
+ not be registered as <em>conffile</em>s or otherwise treated as
+ configuration files. Customization of programs' X resources may
+ be supported with the provision of a file with the same name as
+ that of the package placed in the <tt>/etc/X11/Xresources/</tt>
+ directory, which should be registered as a <em>conffile</em>.
<em>Important:</em> packages that install files into the
- <tt>/etc/X11/Xresources/</tt> directory <em>must</em>
- declare a conflict with <tt>xbase (<<
- 3.3.2.3a-2)</tt>; if this is not done it is possible for the
- package to destroy a previously-existing
- <tt>/etc/X11/Xresources</tt> <em>file</em>.</p>
-
- <p>
- No package should ever install files into the directories
- <tt>/usr/bin/X11/</tt>, <tt>/usr/share/doc/X11/</tt>,
- <tt>/usr/include/X11/</tt>, or <tt>/usr/lib/X11/</tt>; these
- directories are actually symbolic links, which <tt>dpkg</tt>
- does not follow when unpacking a package. Instead, use
- <tt>/usr/X11R6/bin/</tt>, <tt>/usr/share/doc/package/</tt>
- (i.e., place files with the rest of your package's
- documentation), <tt>/usr/X11R6/include/</tt>, and
- <tt>/usr/X11R6/lib/</tt>. This restriction governs only the
- paths used by the package as it is unpacked onto the system;
- it is permissible, and even preferable, for files within a
- package (shell scripts, for instance) to refer to the
- <tt>/usr/{bin,include,lib}/X11/</tt> directories rather than
- their <tt>/usr/X11R6/</tt> counterparts -- this way they do
- not have to be modified in the event that the X Window
- System packages install their files into a different
- directory in the future.</p>
+ <tt>/etc/X11/Xresources/</tt> directory <em>must</em> declare a
+ conflict with <tt>xbase (<< 3.3.2.3a-2)</tt>; if this is
+ not done it is possible for the installing package to destroy a
+ previously-existing <tt>/etc/X11/Xresources</tt> <em>file</em>
+ which had been customized by the system administrator.
+ <footnote>
+ <p>Rationale: clarifies the language to properly
+ address the package maintainer, not the system
+ administrator, as to how to manage
+ /etc/X11/Xresources.</p>
+ </footnote>
+ </p>
+
+
+ <p>
+ <em>Packages using the X Window System should abide by the FHS
+ standard whenever possible</em>; they should install binaries,
+ libraries, manual pages, and other files in FHS-mandated
+ locations wherever possible. This means that files should
+ not be installed into <tt>/usr/X11R6/bin/</tt>,
+ <tt>/usr/X11R6/lib/</tt>, or <tt>/usr/X11R6/man/</tt> unless
+ this is necessary for the package to operate properly.
+ Configuration files for window managers and display managers
+ should be placed in a subdirectory of <tt>/etc/X11/</tt>
+ corresponding to the package name due to these programs'
+ tight integration with the mechanisms of the X Window
+ System. Application-level programs should use the
+ <tt>/etc/</tt> directory unless otherwise mandated by
+ policy. The installation of files into subdirectories of
+ <tt>/usr/X11R6/include/X11/</tt> and
+ <tt>/usr/X11R6/lib/X11/</tt> is permitted but discouraged;
+ package maintainers should determine if subdirectories of
+ <tt>/usr/lib/</tt> and <tt>/usr/share/</tt> can be used
+ instead (symlinks from the X11R6 directories to
+ FHS-compliant locations is encouraged if the program is not
+ easily configured to look elsewhere for its files).
+ Packages must not provide -- or install files into -- the
+ directories <tt>/usr/bin/X11/</tt>,
+ <tt>/usr/include/X11/</tt>, or <tt>/usr/lib/X11/</tt>.
+ Files within a package should, however, make reference to
+ these directories, rather than their X11R6-named
+ counterparts <tt>/usr/X11R6/bin/</tt>,
+ <tt>/usr/X11R6/include/X11/</tt>, and
+ <tt>/usr/X11R6/lib/X11/</tt>, if the resources being
+ referred to have not been moved to FHS-compliant locations.
+ </p>
<p>
- If you package a program that requires the (non-free)
- OSF/Motif library, you should try to determine whether the
- programs works reasonably well with the free
- re-implementation of Motif called LessTif. If so, build the
- package using the LessTif libraries; it can then go into the
- main section of the package repository and become an
- official part of the Debian distribution.</p>
-
- <p>
- If however, the Motif-based program works insufficiently
- well with LessTif, you should instead provide "-smotif" and "-dmotif"
- versions (appending these identifiers to the name of the
- package), which are statically and dynamically linked
- against the Motif libraries, respectively. (All known
- versions of OSF/Motif permit redistribution of
- statically-linked binaries using the library, but check the
- license on your copy of Motif to be sure.) This two-package
- approach allows users without Motif to use the package,
- whereas users with Motif installed can enjoy the advantages
- of the dynamically-linked version (a considerable savings in
- disk space usage, download time, etc.). Neither "-smotif"
- nor "-dmotif" packages can go into the main section; if the
- licensing on the package is compatible with the Debian Free
- Software Guidelines, it may go into the contrib section;
- otherwise it must go into the non-free section.
-
+ <em>Programs that require the non-DFSG-compliant OSF/Motif
+ library</em> should be compiled against and tested with
+ LessTif (a free re-implementation of Motif) instead. If the
+ maintainer judges that the program or programs do not work
+ sufficiently well with LessTif to be distributed and
+ supported, but do so when compiled against Motif, then two
+ versions of the package should be created; one linked
+ statically against Motif and with <tt>-smotif</tt> appended
+ to the package name, and one linked dynamically against
+ Motif and with <tt>-dmotif</tt> appended to the package
+ name. Both Motif-linked versions are dependent upon
+ non-DFSG-compliant software and thus cannot be uploaded to
+ the main distribution; if the software is itself
+ DFSG-compliant it may be uploaded to the contrib
+ distribution. While known existing versions of OSF/Motif
+ permit unlimited redistribution of binaries linked against
+ the library (whether statically or dynamically), it is the
+ package maintainer's responsibility to determine whether
+ this is permitted by the license of the copy of OSF/Motif in
+ his or her possession.
</p>
</sect>
changelog files do not already conform to this naming
convention, then this may be achieved by either renaming the
files or adding a symbolic link at the packaging developer's
- discretion. </p>
+ discretion.
+ <footnote>
+ <p>
+ Rationale: People should not have to look into two
+ places ofr upstream changelogs merely because they are
+ in HTML format.
+ </p>
+ </footnote>
+ </p>
<p>
Both should be installed compressed using <tt>gzip -9</tt>,
Created On : Thu Oct 29 20:54:48 1998
Created On Node : tiamat.datasync.com
Last Modified By : Manoj Srivastava
- Last Modified On : Wed Jun 30 12:35:32 1999
+ Last Modified On : Fri Mar 17 14:31:26 2000
Last Machine Used: glaurung.green-gryphon.com
- Update Count : 7
+ Update Count : 10
Status : Unknown, Use with caution!
HISTORY :
Description :
<h2>The checklist</h2>
<pre>
+4.0.0.0 Mar 00
+
+ Policy Manual:
+ - 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.
+ - 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.
+ - Please note that the new release of the X window system (4.x)
+ shall probably need sweeping changes in policy.
+ - Policy for packages providing an X server has been codified
+ (formalizes existing practice - use virtual package xserver)
+ - Policy for packages providing an X terminal emulator has been
+ codified (use virtual package x-terminal-emulator)
+ - Policy for packages providing an X window manager has been
+ codified (use virtual package x-window-anager, and also as an
+ alternative for /usr/bin/x-window-manager. The policy has
+ guidelines on how to calculate priority)
+ - Policy for packages providing an X fonts has been
+ codified. Please look into the manual for details; this section
+ has been written from scratch.
+ - Policy for packages using the X Window System and FHS issues
+ has been clarified. Please read the manual for details.
+ - Policy for packages providing an X application default has been
+ clarified.
+
+ Packaging Manual:
+ - Noted that newer dpkg versions do not require extreme care in
+ always creating theshared lib before the symlink, so the unpack
+ order be correct.
+
3.1.1.0 Nov 99
Packaging Manual:
Now, the list:
-X Windows
----------
-xserver Any X server (used by other X packages)
+X Window System
+ ---------
+x-terminal-emulator any X client which emulates a terminal with a
+ terminfo description in the ncurses-base package
+x-window-manager any X client which provides window management
+ services
+xserver any X server that (directly or indirectly) manages
+ physical input and display hardware
Miscellaneous
-------------
projects / debian / debian-policy.git / commitdiff