Please keep me up to date on all happenings in the policy department, thanks soo much, sincerely Jared Chiddix liblockfile1 (>>1.01)

You will need to depend on liblockfile1 (>>1.01) to use these functions.

103

There are two traditional permission schemes for mail spools: mode 600 with all mail delivery done by processes running as the destination user, or mode 660 and owned by group mail with mail delivery done by a process running as a system user in group mail. Historically, Debian required mode 660 mail spools to enable the latter model, but that model has become increasingly uncommon and the principle of least privilege indicates that mail systems that use the first model should use permissions of 600. If delivery to programs is permitted, it's easier to keep the mail system secure if the delivery agent runs as the destination user. Debian Policy therefore permits either scheme.

104

This implements current practice, and provides 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.

105

"New terminal window" does not necessarily mean a new top-level X window directly parented by the window manager; it could, if the terminal emulator application were so coded, be a new "view" in a multiple-document interface (MDI).

106

For the purposes of Debian Policy, a "font for the X Window System" is one which is accessed via X protocol requests. Fonts for the Linux console, for PostScript renderer, or any other purpose, do not fit this definition. Any tool which makes such fonts available to the X Window System, however, must abide by this font policy.

107

This is because the X server may retrieve fonts from the local file system or over the network from an X font server; the Debian package system is empowered to deal only with the local file system.

108

Note that this mechanism is not the same as using app-defaults; app-defaults are tied to the client binary on the local file system, whereas X resources are stored in the X server and affect all connecting clients.

109

It is not very hard to write a man page. See the Man-Page-HOWTO, man(7), the examples created by dh_make, the helper program help2man, or the directory /usr/share/doc/man-db/examples.

110

Supporting this in man often requires unreasonable processing time to find a manual page or to report that none exists, and moves knowledge into man's database that would be better left in the file system. This support is therefore deprecated and will cease to be present in the future.

111

man will automatically detect whether UTF-8 is in use. In future, all manual pages will be required to use UTF-8.

112

At the time of writing, Chinese and Portuguese are the main languages with such differences, so pt_BR, zh_CN, and zh_TW are all allowed.

113

Normally, info documents are generated from Texinfo source. To include this information in the generated info document, if it is absent, add commands like:

     @dircategory Individual utilities
     @direntry
     * example: (example).               An example info directory entry.
     @end direntry

to the Texinfo source of the document and ensure that the info documents are rebuilt from source during the package build.

114

The system administrator should be able to delete files in /usr/share/doc/ without causing any programs to break.

115

Please note that this does not override the section on changelog files below, so the file /usr/share/doc/package/changelog.Debian.gz must refer to the changelog for the current version of package in question. In practice, this means that the sources of the target and the destination of the symlink must be the same (same source package and version).

116

At this phase of the transition, we no longer require a symbolic link in /usr/doc/. At a later point, policy shall change to make the symbolic links a bug.

117

The rationale: The important thing here is that HTML docs should be available in some package, not necessarily in the main binary package.

118

In particular, /usr/share/common-licenses/Apache-2.0, /usr/share/common-licenses/Artistic, /usr/share/common-licenses/GPL-1,/usr/share/common-licenses/GPL-2, /usr/share/common-licenses/GPL-3, /usr/share/common-licenses/LGPL-2, /usr/share/common-licenses/LGPL-2.1, /usr/share/common-licenses/LGPL-3, /usr/share/common-licenses/GFDL-1.2, and /usr/share/common-licenses/GFDL-1.3 respectively. The University of California BSD license is also included in base-files as /usr/share/common-licenses/BSD, but given the brevity of this license, its specificity to code whose copyright is held by the Regents of the University of California, and the frequency of minor wording changes, its text should be included in the copyright file rather than referencing this file.

119

Rationale: People should not have to look in places for upstream changelogs merely because they are given different names or are distributed in HTML format.

120

dpkg is targeted primarily at Debian, but may work on or be ported to other systems.

121

This is so that the control file which is produced has the right permissions

122

This is not currently detected when building source packages, but only when extracting them.

123

Hard links may be permitted at some point in the future, but would require a fair amount of work.

124

Setgid directories are allowed.

125

Renaming a file is not treated specially - it is seen as the removal of the old file (which generates a warning, but is otherwise ignored), and the creation of the new one.

Debian Policy Manual

version 3.9.5.0, 2013-10-28

The Debian Policy Mailing List

Using CVS

CVS is a program to help manage having multiple people work on the same material simultaneously. Every user creates a local copy of the main repository. The local copies can be on the same machine, or across the world. Users can then modify the local copy as they wish and when the modified material is ready, commit the changes back to the main repository.

For a read only access it's possible to use the web frontend. There exist also many graphical CVS clients such as KDE's cervisia. This document describes the workflow with the command line program cvs, other clients provide similar functionality.

CVS will not let you commit a file if the copy in the main repository has been modified since your last update. This is not normally a problem as you can still update your local copy. If the modifications were to different parts than you were working on, the changes are silently merged. If the changes affect the same area you were working on, you will be warned that there is a conflict and you need to edit the file to fix the problem before committing.

In what follows anonymous access will be used as an example. If you have access to another account which gives you write permission to the repository then you should use that account instead. If you are planning on making changes, you should get an account before starting as anonymous users cannot commit changes. See the section on write access for more information.

To begin using CVS, you must first login to the CVS server

cvs -d :pserver:anonymous@anonscm.debian.org:/cvs/webwml login

(just hit enter for the password here)

To check out a copy of the wml files on your local machine, you need to use

cvs -d :pserver:anonymous@anonscm.debian.org:/cvs/webwml checkout webwml

You can check out a subset of the pages like this:

cvs -d :pserver:anonymous@anonscm.debian.org:/cvs/webwml checkout -l \

webwml webwml/<language>

cvs -d :pserver:anonymous@anonscm.debian.org:/cvs/webwml checkout \

webwml/Perl webwml/english/template webwml/<language>/Pics

cvs -d :pserver:anonymous@anonscm.debian.org:/cvs/webwml checkout \

webwml/<language>/<path to desired files>

Repeat for all subdirectories or files that you want. The second line includes all the files you will need if you wish to create HTML from the WML files. Partial checkouts such as these aren't really supported, though, so the above instructions may not always work.

If you have an Alioth account, with an associated public SSH key, you can use it instead like this:

cvs -d :ext:username@cvs.debian.org:/cvs/webwml checkout webwml/english/doc

From then on, you will not need to use the '-d :ext:...' part. Every few days you will want to do a

cvs update -d

to retrieve any files from the repository which have changed. The -d update option will add any new directories, automatically. It will also check out all the directories that were omitted if you performed a partial checkout — in that case you might want to use the cvsup.py script.

You may want to create a ~/.cvsrc file so that you don't have to type some options all the time. For example, it can contain:

cvs -z9

update -d -P

diff -u

The following is for those who have write permission on the repository. When you are done with a page, you can commit your changes to the repository using

cvs commit <file>.wml

cvs commit <dir> (to commit all the changes in <dir>)

cvs commit (to commit all changes from the current dir down)

If you are the first person translating a page, you need to do

cvs add <file>.wml

before you commit it. Note that cvs add is not recursive so you need to add a directory before you can add its contents.

For more information on CVS, use info cvs.

If you include Closes: #nnnnnn in your commit log entry then bug number #nnnnnn will be closed automatically when you commit. The precise form of this is the same as in Debian policy.

Please do not include HTTPS links to Debian, DebConf or SPI websites. Currently the SSL certificates for all of these are signed by the SPI Certificate Authority, which is trusted by machines running Debian but not generally by browsers on other platforms. Using HTTPS links for Debian websites means that visitors may encounter confusing SSL errors from their browsers and complain to Debian about it. The CVS repository will reject commits containing HTTPS links for some parts of the Debian websites that are known to not need SSL.

CVS Write Access

If you already know how to help, and have provided enough patches that have been accepted by the web team or a localization team, you could obtain write access to the website: please request to join the webwml project on Alioth (you will have to create an Alioth account if you don't already have one). Please write something useful in your request, like which language or which part of the website you plan to work on, and who would vouch for you.

Again, dh_shlibdeps and dh_gencontrol will handle everything except the addition of the variable to the control file for you if you're using debhelper, including generating separate substvars files for each binary package and calling dpkg-gencontrol with the appropriate flags.

A good example of where this helps is the following. We could update libimlib with a new version that supports a new revision of a graphics format called dgf (but retaining the same major version number) and depends on a new library package libdgf4 instead of the older libdgf3. If we used ldd to add dependencies for every library directly or indirectly linked with a binary, every package that uses libimlib would need to be recompiled so it would also depend on libdgf4 in order to retire the older libdgf3 package. Since dependencies are only added based on ELF NEEDED attribute, packages using libimlib can rely on libimlib itself having the dependency on an appropriate version of libdgf and do not need rebuilding.

An example of an "unreasonable" program is one that uses library interfaces that are documented as internal and unsupported. If the only programs or libraries affected by a change are "unreasonable" ones, other techniques, such as declaring Breaks relationships with affected packages or treating their usage of the library as bugs in those packages, may be appropriate instead of changing the SONAME. However, the default approach is to change the SONAME for any change to the ABI that could break a program.

An example may clarify. Suppose the source package foo generates two binary packages, libfoo2 and foo-runtime. When building the binary packages, the contents of the packages are staged in the directories debian/libfoo2 and debian/foo-runtime respectively. (debian/tmp could be used instead of one of these.) Since libfoo2 provides the libfoo shared library, it will contain a symbols file, which will be installed in debian/libfoo2/DEBIAN/symbols, eventually to be included as a control file in that package. When dpkg-shlibdeps is run on the executable debian/foo-runtime/usr/bin/foo-prog, it will examine the debian/libfoo2/DEBIAN/symbols file to determine whether foo-prog's library dependencies are satisfied by any of the libraries provided by libfoo2. Since those binaries were linked against the just-built shared library as part of the build process, the symbols file for the newly-built libfoo2 must take precedence over a symbols file for any other libfoo2 package already installed on the system.

This can be determined by using the command

readelf -d /usr/lib/libz.so.1.2.3.4 | grep SONAME

An example of where this may be needed is with a library that implements the libGL interface. All GL implementations provide the same set of base interfaces, and then may provide some additional interfaces only used by programs that require that specific GL implementation. So, for example, libgl1-mesa-glx may use the following symbols file:

libGL.so.1 libgl1

| libgl1-mesa-glx #MINVER#

publicGlSymbol@Base 6.3-1

[...]

implementationSpecificSymbol@Base 6.5.2-7 1

[...]

Binaries or shared libraries using only publicGlSymbol would depend only on libgl1 (which may be provided by multiple packages), but ones using implementationSpecificSymbol would get a dependency on libgl1-mesa-glx (>= 6.5.2-7)

This field should normally not be necessary, since if the behavior of any symbol has changed, the corresponding symbol minimal-version should have been increased. But including it makes the symbols system more robust by tightening the dependency in cases where the package using the shared library specifically requires at least a particular version of the shared library development package for some reason.