X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;f=policy.sgml;h=b27c9da5d95f5bd10a033705f1558344e347d994;hb=907905af29883401668ca56652c6b9e0a75f75fe;hp=0a924f78b42f7fb3b70625ca262f9f72b3989f92;hpb=85949103f425b1d83cb3a514176ca766e7e85432;p=debian%2Fdebian-policy.git diff --git a/policy.sgml b/policy.sgml index 0a924f7..b27c9da 100644 --- a/policy.sgml +++ b/policy.sgml @@ -24,6 +24,13 @@ Copyright © 1996,1997,1998 Ian Jackson and Christian Schwarz. +

+ These are the copyright dates of the original Policy manual. + Since then, this manual has been updated by many others. No + comprehensive collection of copyright notices for subsequent + work exists. +

+

This manual is free software; you may redistribute it and/or modify it under the terms of the GNU General Public License @@ -1985,6 +1992,12 @@ DEB_*_ARCH (the Debian architecture) + + DEB_*_ARCH_CPU (the Debian CPU name) + + + DEB_*_ARCH_OS (the Debian System name) + DEB_*_GNU_TYPE (the GNU style architecture specification string) @@ -2013,8 +2026,10 @@ It is important to understand that the DEB_*_ARCH string only determines which Debian architecture we are building on or for. It should not be used to get the CPU - or system information; the GNU style variables should be - used for that. + or system information; the DEB_*_ARCH_CPU and + DEB_*_ARCH_OS variables should be used for that. + GNU style variables should generally only be used with upstream + build systems.

@@ -2710,7 +2725,7 @@ Package: libc6 values: A unique single word identifying a Debian machine - architecture, see . + architecture as described in . all, which indicates an architecture-independent package. any, which indicates a package available @@ -2721,31 +2736,53 @@ Package: libc6

In the main debian/control file in the source - package, or in the source package control file - .dsc, one may specify a list of architectures - separated by spaces, or the special values any or - all. + package, this field may contain the special value + any, the special value all, or a list of + architectures separated by spaces. If any or + all appear, they must be the entire contents of the + field. Most packages will use either any or + all. Specifying a specific list of architectures is + for the minority of cases where a program is not portable or + is not useful on some architectures, and where possible the + program should be made portable instead. +

+ +

+ In the source package control file .dsc, this + field may contain either the special value any or a + list of architectures separated by spaces. If a list is given, + it may include (or consist solely of) the special value + all. In other words, in .dsc files + unlike the debian/control, all may occur + in combination with specific architectures. The + Architecture field in the source package control file + .dsc is generally constructed from the + Architecture fields in the + debian/control in the source package.

Specifying any indicates that the source package isn't dependent on any particular architecture and should compile fine on any one. The produced binary package(s) - will be specific to whatever the current build architecture - is. - This is the most often used setting, and is recommended - for new packages that aren't Architecture: all. - + will either be specific to whatever the current build + architecture is or will be architecture-independent. +

+ +

+ Specifying only all indicates that the source package + will only build architecture-independent packages. If this is + the case, all must be used rather than any; + any implies that the source package will build at + least one architecture-dependent package.

Specifying a list of architectures indicates that the source will build an architecture-dependent package, and will only - work correctly on the listed architectures. - This is a setting used for a minority of cases where the - program is not portable. Generally, it should not be used - for new packages. - + work correctly on the listed architectures. If the source + package also builds at least one architecture-independent + package, all will also be included in the list.

@@ -2753,7 +2790,11 @@ Package: libc6 field lists the architecture(s) of the package(s) currently being uploaded. This will be a list; if the source for the package is also being uploaded, the special - entry source is also present. + entry source is also present. all will be + present if any architecture-independent packages are being + uploaded. any may never occur in the + Architecture field in the .changes + file.

@@ -3084,76 +3125,39 @@ Package: libc6 distribution(s) where this version of the package should be installed. Valid distributions are determined by the archive maintainers. - Current distribution names are: + Example distribution names in the Debian archive used in + .changes files are: - stable - - This is the current "released" version of Debian - GNU/Linux. Once the distribution is - stable only security fixes and other - major bug fixes are allowed. When changes are - made to this distribution, the release number is - increased (for example: 2.2r1 becomes 2.2r2 then - 2.2r3, etc). - - unstable - This distribution value refers to the - developmental part of the Debian - distribution tree. New packages, new upstream - versions of packages and bug fixes go into the - unstable directory tree. Download from - this distribution at your own risk. - - - testing - - This distribution value refers to the - testing part of the Debian distribution - tree. It receives its packages from the - unstable distribution after a short time lag to - ensure that there are no major issues with the - unstable packages. It is less prone to breakage - than unstable, but still risky. It is not - possible to upload packages directly to - testing. - - - frozen - - From time to time, the testing - distribution enters a state of "code-freeze" in - anticipation of release as a stable - version. During this period of testing only - fixes for existing or newly-discovered bugs will - be allowed. The exact details of this stage are - determined by the Release Manager. + This distribution value refers to the + developmental part of the Debian distribution + tree. Most new packages, new upstream versions of + packages and bug fixes go into the unstable + directory tree. experimental - The packages with this distribution value are - deemed by their maintainers to be high - risk. Oftentimes they represent early beta or - developmental packages from various sources that - the maintainers want people to try, but are not - ready to be a part of the other parts of the - Debian distribution tree. Download at your own - risk. + The packages with this distribution value are deemed + by their maintainers to be high risk. Oftentimes they + represent early beta or developmental packages from + various sources that the maintainers want people to + try, but are not ready to be a part of the other parts + of the Debian distribution tree.

- You should list all distributions that the - package should be installed into. -

- -

- More information is available in the Debian Developer's - Reference, section "The Debian archive". + Others are used for updating stable releases or for + security uploads. More information is available in the + Debian Developer's Reference, section "The Debian + archive".

+ The Debian archive software only supports listing a single + distribution. Migration of packages to other distributions is + handled outside of the upload process.

@@ -3294,8 +3298,9 @@ Package: libc6

- The disk space is represented in kilobytes as a simple - decimal number. + The disk space is given as the integer value of the installed + size divided by 1024 (in other words, the size in kibibytes) + and rounded up.

@@ -8572,54 +8577,34 @@ name ["syshostname"]: Installation directory issues

- Packages using the X Window System should not be - configured to install files under the - /usr/X11R6/ directory. The - /usr/X11R6/ directory hierarchy should be + Historically, packages using the X Window System used a + separate set of installation directories from other packages. + This practice has been discontinued and packages using the X + Window System should now generally be installed in the same + directories as any other package. Specifically, packages must + not install files under the /usr/X11R6/ directory + and the /usr/X11R6/ directory hierarchy should be regarded as obsolete.

- Programs that use GNU autoconf and - automake are usually easily configured at - compile time to use /usr/ instead of - /usr/X11R6/, and this should be done whenever - possible. 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 now prohibited; - package maintainers should determine if subdirectories of - /usr/lib/ and /usr/share/ can be used - instead. + Include files previously installed under + /usr/X11R6/include/X11/ should be installed into + /usr/include/X11/. For files previously + installed into subdirectories of + /usr/X11R6/lib/X11/, package maintainers should + determine if subdirectories of /usr/lib/ and + /usr/share/ can be used. If not, a subdirectory + of /usr/lib/X11/ should be used.

- Packages should install any relevant files into the - directories /usr/include/X11/ and - /usr/lib/X11/, but if they do so, they must - pre-depend on x11-common (>= - 1:7.0.0) -

- These libraries used to be all symbolic - links. However, with X11R7, - /usr/include/X11 and /usr/lib/X11 - are now real directories, and packages - should ship their files here instead - of in /usr/X11R6/{include,lib}/X11. - x11-common (>= 1:7.0.0) is the package - responsible for converting these symlinks into - directories. -

- + 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.