Philip Hands
Julian Gilbey
Manoj Srivastava
A copy of the GNU General Public License is available as
/usr/share/common-licences/GPL in the Debian GNU/Linux
distribution or on the World Wide Web at
-
This document assumes familiarity with these other two
@@ -134,16 +140,15 @@
The current version of this document is always accessible from the
- Debian FTP server at
-
In addition, this manual is distributed via the Debian package - debian-policy + debian-policy.
- packages which we don't want to support because they are too - buggy, and -
-- packages which fail to meet some other policy requirements in - a serious way. -
-- The packages in the main, contrib, and - non-free sections are grouped further into - subsections to simplify handling of them.
+ The packages in all the sections (main, + contrib, non-US/main, non-free, + non-US/contrib, and non-US/non-free) are + grouped further into subsections to simplify + handling.
The section for each package is specified in the package's
@@ -585,10 +580,11 @@
- This contains packages that conflict with others with
- higher priorities, or are only likely to be useful if
- you already know what they are or have specialized
+
+ This contains all packages that conflict with others
+ with required, important, standard or optional
+ priorities, or are only likely to be useful if you
+ already know what they are or have specialised
requirements.
Packages may not depend on packages with lower priority - values. If this does happen, one of the priority values - will have to be adapted. + values (excluding build-time dependencies). In order to + ensure this, the priorities of one or more packages may have + to be adjusted.
If the maintainer of a package quits from the Debian
- project the Debian QA Group takes over the maintainership
- of the package until someone else volunteers for that
- task. These packages are called orphaned
- packages.
+ project the Debian QA Group
+
Sometimes, there are several packages doing more-or-less
the same job. In this case, it's useful to define a
- virtual package who's name describes the function
+ virtual package whose name describes the function
the packages have. (The virtual packages just exist
logically, not physically--that's why they are called
virtual.) The packages with this particular
@@ -865,7 +863,7 @@
De-installation of other packages supplying it which do not
(yet) use
+ Source packages must specify which binary packages they + require to be installed or not to be installed in order to + build correctly. For example, if building a package + requires a certain compiler, then the compiler must be + specified as a build-time dependency. +
+ ++ It will not be necessary to explicitly specify build-time + relationships on a minimal set of packages that are always + needed to compile, link and put in a Debian package a + standard "Hello World!" program written in C or C++. The + required packages are called build-essential, and + an informational list can be found in + /usr/share/doc/build-essential/list (which is + contained in the build-essential package). + +
+ ++ When specifying the set of build-time dependencies, one + should list only those packages explicitly required by the + build. It is not necessary to list packages which are + required merely because some other package in the list of + build-time dependencies depends on them. The reason is + that dependencies change, and you should list only those + you need. What others need is their business. +
+ ++ It is a bug if, after unpacking a source package on a + system with the build-essential packages installed and + satisfying the build-time relationships (including the + implied relationships), one cannot build the package and + produce a working binary package suitable for installation + into the binary distribution corresponding to the source + distribution which contained the source package. This + means in particular that version clauses should be used + rigorously in build-time relationships so that one cannot + produce bad or inconsistently configured packages when the + relationships are properly satisfied. +
+
The location of all installed files and directories must
- comply (with some exceptions
- In an as yet unreleased version of the standard, the
- location of the mail spool and state information
- directories has changed; and we propose to follow the
- latter, since that would mean that we do not have to
- move things around again when the new version of the
- FHS comes around). The changes are, amongst others,
- s%/var/mail%/var/spool/mail% and
- s%/var/state%/var/lib% The Debian distribution currently distributes a draft
+ version of FHS 2.1 because several significant details
+ have changed between the currently released 2.0
+ version and the to-be-released 2.1 version.
- The /usr/local directory itself and all the subdirectories - created by the package should have permissions 2775 (group-writable - and set-group-id) and be owned by root.staff.
+ However, because '/usr/local' and its contents are for + exclusive use of the local administrator, a package must + not rely on the presence or absence of files or + directories in '/usr/local' for normal operation. + ++ The /usr/local directory itself and all the + subdirectories created by the package should have + permissions 2775 (group-writable and set-group-id) and be + owned by root.staff.
The /etc/init.d directory contains the scripts
executed by
- - These scripts are being referenced by symbolic links in + section="8">).
+ +
+ There are at least two different, yet functionally
+ equivalent, ways of handling these scripts. For the sake
+ of simplicity, this document describes only the symbolic
+ link method. However, it may not be assumed that this
+ method is being used, and any manipulation of the various
+ runlevel behaviours must be performed using
+
+ These scripts are referenced by symbolic links in
the /etc/rcn.d directories. When
changing runlevels,
+
The names of the links all have the form - Smm/script or - Kmm/script where + Smmscript or + Kmmscript where mm is a two-digit number and script is the name of the script (this should be the same as the - name of the actual script in /etc/init.d. + name of the actual script in /etc/init.d.
+
When
These scripts should not fail obscurely when the
configuration files remain but the package has been
- removed, as the default in
- A program is provided,
You should use this script to make changes to - /etc/rcn.d and never include - any /etc/rcn.d symbolic links in the - actual archive.
+ /etc/rcn.d and never either + include any /etc/rcn.d symbolic links + in the actual archive or manually create or remove the + symbolic links in maintainer scripts. (The latter will + fail if an alternative method of maintaining runlevel + information is being used.)
By default
To get the default behavior for your package, put in your
@@ -1430,32 +1502,15 @@
- There is another directory, /etc/rc.boot, which
- contains scripts which are run once per machine boot.
- This facility is provided for initialization of hardware
- devices, cleaning up of leftover files, and so forth.
- For example, the
- The files in /etc/rc.boot should not be
- links into /etc/init.d--they should be the
- scripts themselves.
- rc.boot should not be used for starting
- general-purpose daemons and similar activities. This
- should be done using the rcn.d scheme,
- above, so that the services can be started and stopped
- cleanly when the runlevel changes or the machine is to be
- shut down or rebooted.
+ There used to be another directory, /etc/rc.boot,
+ which contained scripts which were run once per machine
+ boot. This has been deprecated in favour of links from
+ /etc/rcS.d to files in /etc/init.d as
+ described in . No packages may
+ place files in /etc/rc.boot.
@@ -1464,19 +1519,23 @@
.deb file system archive! This will cause
problems! You should create them with
- Do not include the /etc/rcn.d/* symbolic links in
+ Do not include the
+ /etc/rcn.d/* symbolic links in
- Packages may not touch the configuration file + Packages may not modify the configuration file /etc/crontab, nor may they modify the files in /var/spool/cron/crontabs.
@@ -1574,36 +1633,37 @@ /etc/cron.weekly /etc/cron.monthly - As these directory names say, the files within them are executed on - a daily, weekly, or monthly basis, respectively. - + As these directory names imply, the files within them are + executed on a daily, weekly, or monthly basis, + respectively. The exact times are listed in + /etc/crontab. + ++ All files installed in any of these directories have to be + scripts (shell scripts, Perl scripts, etc.) so that they can + easily be modified by the local system administrator. In + addition, they must be treated as configuration files.
+
If a certain job has to be executed more frequently than
- `daily,' the package should install a file
- /etc/cron.d/<package-name> tagged as
- configuration file. This file uses the same syntax as
- /etc/crontab and is processed by
- All files installed in any of these directories have to be - scripts (shell scripts, Perl scripts, etc.) so that they can - easily be modified by the local system administrator. In - addition, they have to be registered as configuration - file.
- +- The scripts in these directories have to 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 the configuration files are - kept on the system in this situation.
- - + The scripts or crontab 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. + +
Menu entries should follow the current menu policy as
defined in the file
@@ -1815,9 +1876,38 @@ Please refer to the Debian Menu System document that comes with the menu package for information about how to register your applications and web - documents.
+ Packages which provide the ability to view/show/play,
+ compose, edit or print MIME types should register themselves
+ as such following the current MIME support policy as defined
+ in the file found on
+ MIME (Multipurpose Internet Mail Extensions, RFC 1521) is a + mechanism for encoding files and data streams and providing + meta-information about them, in particular their type (e.g. + audio or video) and format (e.g. PNG, HTML, MP3). +
+ ++ Registration of MIME type handlers allows programs like mail + user agents and web browsers to to invoke these handlers to + view, edit or display MIME types they don't support + directly. +
+Some systems (including previous Debian versions) use xmodmap to arrange for both <-- and Delete - to generate KB_Delete). We can change the behavior + to generate KB_Delete. We can change the behavior of their X clients via the same X resources that we use to do it for our own, or have our clients be configured via their resources when things are the @@ -1981,53 +2071,109 @@
- 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, both programs must be - renamed.
- -
- Generally the following compilation parameters should be used:
-
- Note that all installed binaries should be stripped,
- either by using the -s flag to
-
- The -g 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.
- -- The -N 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.
- -+
+ 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, both programs must be + renamed.
+ +
+ Generally the following compilation parameters should be used:
+
+ Note that by default all installed binaries should be stripped,
+ either by using the -s flag to
+
+ The -N 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.
+ +
+ 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 DEB_BUILD_OPTIONS
+ contains the string debug, compile the software with
+ debugging information (usually this involves adding the
+ -g flag to CFLAGS). This allows to generate
+ a build tree with debugging information. If the environment
+ variable DEB_BUILD_OPTIONS contains the
+ string nostrip, 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:
+
+ 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.
+ Now this has several added benefits:
+
+ 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.
+ 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,
+
+
+
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 @@ -2076,14 +2222,14 @@
An ever increasing number of packages are using libtool to do their linking. The latest GNU libtools (>= 1.3a) can take - advantage of installed libtool archive files (`*.la'). The - main advantage of libtool's .la files is that it allows - libtool to store and subsequently access metadata with - respect to the libraries it builds. libtool will search for - those files, which contain a lot of useful information about - a library (e.g. dependency libraries for static - linking). Also, they're essential for programs using - libltdl. + advantage of the metadata in the installed libtool archive + files (`*.la'). The main advantage of libtool's .la files is + that it allows libtool to store and subsequently access + metadata with respect to the libraries it builds. libtool + will search for those files, which contain a lot of useful + information about a library (e.g. dependency libraries for + static linking). Also, they're essential for + programs using libltdl.
@@ -2101,8 +2247,11 @@
Packages that use libtool to create shared libraries must include the .la files in the -dev - packages. This is a good idea in general, and especially - for static linking issues. + packages, with the exception that if the package relies on + libtool's libltdl library, in which case the .la + files must go in the run-time library package. This is a + good idea in general, and especially for static linking + issues.
@@ -2327,90 +2476,252 @@ Debian uses the serial devices /dev/tty*. Programs using the old /dev/cu* devices should be changed to use - /dev/tty*.
+
+ A file that affects the operation of program, or
+ provides site- or host-specific information, or
+ otherwise customizes the behavior of program.
+ Typically, configuration files are intended to be
+ modified by the system administrator (if needed or
+ desired) to conform to local policy or provide more
+ useful site-specific behavior.
+ A file listed in a package's conffiles
+ file, and is treated specially by
+ The distinction between these two is important; they are + not interchangeable concepts. Almost all + conffiles are configuration files, but many + configuration files are not conffiles.
+ ++ Note that a script that embeds configuration information + (such as most of the files in /etc/init.d and + /etc/cron.{daily,weekly,monthly}) is de-facto a + configuration file and should be treated as such.
+Any configuration files created or used by your package - should reside in /etc. If there are several you - should consider creating a subdirectory named after your - package.
- + should reside in /etc. If there are several you + should consider creating a subdirectory of /etc + named after your package. +
- It is almost certain that any file in /etc that
- is in your package's file system archive should be listed
- in
+ Configuration file handling must conform to the following
+ behavior:
+ local changes must be preserved during a package
+ upgrade configuration files should be preserved when the
+ package is removed, and only deleted when the
+ package is purged.
+
+ The easy way to achieve this behavior is to make the + configuration file a conffile. This is + appropriate if it is possible to distribute a default + version that will work for most installations, although + some system administrators may choose to modify it. This + implies that the default version will be part of the + package distribution, and must not be modified by the + maintainer scripts during installation (or at any other + time).
+ +
+ In order to ensure that local changes are preserved
+ correctly, no package may contain or make hard links to
+ conffiles.
+
+ Rationale: There are two problems with hard links.
+ The first is that some editors break the link while
+ editing one of the files, so that the two files may
+ unwittingly become different. The second is that
+
+ The other way to do it is to via the maintainer scripts.
+ In this case, the configuration file must not be listed as
+ a conffile and must not be part of the package
+ distribution. If the existence of a file is required for
+ the package to be sensibly configured it is the
+ responsibility of the package maintainer to write scripts
+ which correctly create, update, maintain and
+ remove-on-purge the file. These scripts must be idempotent
+ (i.e. must work correctly if
+ The scripts need not configure every possible option for + the package, but only those necessary to get the package + running on a given system. Ideally the sysadmin should not + have to do any configuration other than that done + (semi-)automatically by the postinst script.
+ +
+ A common practice is to create a script called
+ package-configure and have the
+ package's postinst call it if and only if the
+ configuration file does not already exist. In certain
+ cases it is useful for there to be an example or template
+ file which the maintainer scripts use. Such files should
+ be in /usr/share/doc if they are examples or
+ /usr/lib if they are templates, and should be
+ perfectly ordinary
+ These two styles of configuration file handling must
+ not be mixed, for that way lies madness:
+
Only packages that are tagged conflicting with each other may specify the same file as - conffile. A package may not modify a - configuration file of another package.
- + conffile. +- If two or more packages use the same configuration file, - one of these packages has to be defined as owner - of the configuration file, i.e., it has to list the file - as conffile and has to provide a program that - modifies the configuration file.
- + The maintainer scripts should not alter the conffile of + any package, including the one the scripts belong + to. +- The other packages have to depend on the owner - package and use that program to update the configuration - file.
- + If two or more packages use the same configuration file + and it is reasonable for both to be installed at the same + time, one of these packages must be defined as + owner of the configuration file, i.e. it will be + the package to list that distributes the file and lists it + as a conffile. Other packages that use the + configuration file should depend on the owning package if + they require the configuration file to operate. If the + other package will use the configuration file if present, + but is capable of operating without it, no dependency need + be declared. +
- Sometimes it's appropriate to build a new package, which
- just provides the basic infrastructure for the
- other packages and which manages the shared configuration
- files. (Check out the
+ have one of the related packages (the "core" + package) manage the configuration file with + maintainer scripts as described in the previous + section.
++ the core package should also provide a program that + the other packages may use to modify the + configuration file.
++ the related packages must use the provided program + to make any modifications to the configuration file. + They should either depend on the core package to + guarantee that the configuration modifier program is + available or accept gracefully that they cannot + modify the configuration file if it is not.
++ Sometimes it's appropriate to create a new package which + provides the basic infrastructure for the other packages + and which manages the shared configuration files. (Check + out the sgml-base package as an example.)
+
Files in /etc/skel will automatically be copied
- into new user accounts by
Therefore, if a program needs a dotfile to exist in advance in $HOME to work sensibly that dotfile should be installed in /etc/skel (and listed in conffiles, if it is not generated and modified dynamically by the package's installation scripts).
- +However, programs that require dotfiles in order to operate sensibly (dotfiles that they do not create themselves automatically, that is) are a bad thing, and programs should be configured by the Debian default installation as close to normal as possible.
- +Therefore, if a program in a Debian package needs to be configured in some way in order to operate sensibly that configuration should be done in a site-wide global - configuration file elsewhere in /etc. Only if - the program doesn't support a site-wide default - configuration and the package maintainer doesn't have time - to add it should a default per-user file be placed in + configuration file elsewhere in /etc. Only if the + program doesn't support a site-wide default configuration + and the package maintainer doesn't have time to add it + should a default per-user file be placed in /etc/skel.
- +/etc/skel should be as empty as we can make it. This is particularly true because there is no easy mechanism for ensuring that the appropriate dotfiles are copied into the accounts of existing users when a package is installed.
- -- Ideally the sysadmin should not have to do any - configuration other than that done (semi-)automatically by - the postinst script.
+A better scheme is to use logrotate, a GPL'd program developed by Red Hat, which centralizes log management. It - has both a config file (/etc/logrotate.conf) and a - directory where packages can drop logrotation info + has both a configuration file (/etc/logrotate.conf) + and a directory where packages can drop logrotation info (/etc/logrotate.d).
@@ -2621,10 +2932,10 @@
If a package wants to install an example entry into
/etc/inetd.conf, the entry has to be preceded with
- exactly one hash character (#). Such lines are treated as
- `commented out by user' by the
These two files are managed through `alternatives.' That is, every package providing an editor or pager has to call the - `update-alternatives' script to register these programs.
+If it is very hard to adapt a program to make us of the EDITOR and PAGER variable, that program should be configured - to use `/usr/bin/sensible-editor' and - `/usr/bin/sensible-pager' as editor or pager program, + to use /usr/bin/sensible-editor and + /usr/bin/sensible-pager as editor or pager program, respectively. These are two scripts provided in the Debian base system that check the EDITOR and PAGER variables and launches the appropriate program or falls back to - `/usr/bin/editor' and `/usr/bin/pager', automatically.
+ /usr/bin/editor and /usr/bin/pager, + automatically. ++ A program may also use the VISUAL environment variable to + determine the user's choice of editor. If it exists, it + should take precedence over EDITOR. This is in fact what + /usr/bin/sensible-editor does.
+Since the Debian base system already provides an editor and a pager program, there is no need for a package to depend on @@ -2716,7 +3035,11 @@
Html documents for a package are stored in
- /usr/share/doc/package and can be referred to as
+ /usr/share/doc/package but should
+ be accessed via symlinks as
+ /usr/doc/package
- All Debian MUAs and MTAs have to use the maillock - and mailunlock functions provided by the - liblockfile packages to lock and unlock mail - boxes. These functions implement a NFS-safe locking - mechanism. (It is ok if MUAs and MTAs don't link against - liblockfile but use a compatible mechanism. Please - compare the mechanisms very carefully!)
- + All Debian MUAs, MTAs, MDAs and other mailbox accessing + programs (like IMAP daemons) have to lock the mailbox in a + NFS-safe way. This means that fcntl() locking has + to be combined with dot locking. To avoid dead locks, a + program has to use fcntl() first and dot locking + after this or alternatively implement the two locking + methods in a non blocking way+ If it is not possible to establish both locks, the + system shouldn't wait for the second lock to be + established, but remove the first lock, wait a (random) + time, and start over locking again.
++ liblockfile version >>1.01
+Mailboxes are generally 660 user.mail unless the user has chosen otherwise. A MUA may remove a @@ -2876,74 +3211,288 @@ contains X shared libraries). Users who wish to use the program can install just the relatively small xfree86-common and xlib6g packages, and do - not need to install the whole of X.
+ not need to install the whole of X. +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.
+Do not create two versions (one with X support and one without) of your package.
- Application defaults files have to be installed in
- the directory /usr/X11R6/lib/X11/app-defaults/.
- They are considered as part of the program code. Thus, they
- should not be modified and should not be tagged as
- conffiles. 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
- /etc/X11/Xresources/ directory instead.
+ Packages which provide an X server that, directly or
+ indirectly, communicates with real input and display hardware
+ should declare in their control data that they provide the
+ virtual package xserver.
+
+ 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.
+
+ Packages that provide a terminal emulator for the X + Window System which support a terminal type with a terminfo + description provided in the ncurses-base package + should declare in their control data that they provide the + virtual package x-terminal-emulator. They should + also register themselves as an alternative for + /usr/bin/x-terminal-emulator, with a priority of + 20. +
+ +
+ Packages that provide window managers should declare in
+ their control data that they provide the virtual package
+ x-window-manager. They should also register themselves as an
+ alternative for /usr/bin/x-window-manager, with a priority
+ calculated as follows:
+
+
+
+ Packages that provide fonts for the X Window System
+ 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.
+
+
+
+
+
+ Application defaults files must be installed in the + directory /usr/X11R6/lib/X11/app-defaults/. They should + not be registered as conffiles 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 /etc/X11/Xresources/ + directory, which should be registered as a conffile. Important: packages that install files into the - /etc/X11/Xresources/ directory must - declare a conflict with xbase (<< - 3.3.2.3a-2); if this is not done it is possible for the - package to destroy a previously-existing - /etc/X11/Xresources file.
- -- No package should ever install files into the directories - /usr/bin/X11/, /usr/doc/X11/, - /usr/include/X11/, or /usr/lib/X11/; these - directories are actually symbolic links, which dpkg - does not follow when unpacking a package. Instead, use - /usr/X11R6/bin/, /usr/doc/package/ (i.e., - place files with the rest of your package's documentation), - /usr/X11R6/include/, and - /usr/X11R6/lib/. 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 - /usr/{bin,include,lib}/X11/ directories rather than - their /usr/X11R6/ 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.
+ /etc/X11/Xresources/ directory must declare a + conflict with xbase (<< 3.3.2.3a-2); if this is + not done it is possible for the installing package to destroy a + previously-existing /etc/X11/Xresources file + which had been customized by the system administrator. +Rationale: clarifies the language to properly + address the package maintainer, not the system + administrator, as to how to manage + /etc/X11/Xresources.
+- 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.
- -- 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. + +
+ Packages using the X Window System should abide by the FHS + standard whenever possible; 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 /usr/X11R6/bin/, + /usr/X11R6/lib/, or /usr/X11R6/man/ 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 /etc/X11/ + 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 + /etc/ directory unless otherwise mandated by + policy. The installation of files into subdirectories of + /usr/X11R6/include/X11/ and + /usr/X11R6/lib/X11/ is permitted but discouraged; + package maintainers should determine if subdirectories of + /usr/lib/ and /usr/share/ 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 /usr/bin/X11/, + /usr/include/X11/, or /usr/lib/X11/. + Files within a package should, however, make reference to + these directories, rather than their X11R6-named + counterparts /usr/X11R6/bin/, + /usr/X11R6/include/X11/, and + /usr/X11R6/lib/X11/, if the resources being + referred to have not been moved to FHS-compliant locations. +
++ Programs that require the non-DFSG-compliant OSF/Motif + library 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 -smotif appended + to the package name, and one linked dynamically against + Motif and with -dmotif 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.
- The permissions on /var/lib/games are 755 + The permissions on /var/games are 755 root.root.
@@ -2999,7 +3548,7 @@
As described in the FHS, binaries of games should be installed in the directory /usr/games. This also - applies to games that use the X Window system. Manual pages + applies to games that use the X Window System. Manual pages for games (X and non-X games) should be installed in /usr/share/man/man6.
@@ -3125,7 +3674,44 @@ the instructions for building and installing the package, of course! - + +
+ Former Debian releases placed all additional documentation
+ in /usr/doc/package. To realize a
+ smooth migration to
+ /usr/share/doc/package, each package
+ must maintain a symlink /usr/doc/package
+ that points to the new location of its documentation in
+ /usr/share/doc/package
Any examples (configurations, source files, whatever), should be installed in a directory - /usr/share/doc/package/examples. These files - should not be referenced by any program--they're there for - the benefit of the system administrator and users, as - documentation only.
+ /usr/share/doc/package/examples. These + files should not be referenced by any program--they're there + for the benefit of the system administrator and users, as + documentation only. Architecture-specific example files + should be installed in a directory + /usr/lib/package/examples, and files in + /usr/share/doc/package/examples symlink + to files in it. Or the latter directory may be a symlink to + the former.+ Rationale: People should not have to look into two + places ofr upstream changelogs merely because they are + in HTML format. +
+Both should be installed compressed using gzip -9,