X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;f=policy.sgml;h=ba901bc092dc60d882d16f6fef6e9323dc0ca4d3;hb=fc971fa6bf571ee830a5d3734ea4162cebb86687;hp=88ce8251312ab26e5c9baeeb96b900095d5967c7;hpb=79c24b70e608953066a5611c611fadd3c1e3182d;p=debian%2Fdebian-policy.git diff --git a/policy.sgml b/policy.sgml index 88ce825..ba901bc 100644 --- a/policy.sgml +++ b/policy.sgml @@ -569,8 +569,8 @@ Copyright considerations

- Every package must be accompanied by a verbatim copy of - its copyright and distribution license in the file + Every package must be accompanied by a verbatim copy of its + copyright information and distribution license in the file /usr/share/doc/package/copyright (see for further details).

@@ -689,7 +689,15 @@ ruby, science, shells, sound, tex, text, utils, vcs, video, web, x11, xfce, - zope. + zope. The additional section debian-installer + contains special packages used by the installer and is not used + for normal Debian packages. +

+ +

+ For more information about the sections and their definitions, + see the .

@@ -1638,8 +1646,8 @@ Copyright: debian/copyright

- Every package must be accompanied by a verbatim copy of - its copyright and distribution license in the file + Every package must be accompanied by a verbatim copy of its + copyright information and distribution license in the file /usr/share/doc/package/copyright (see for further details). Also see for further considerations related @@ -2747,8 +2755,8 @@ Package: libc6

In the main debian/control file in the source - package, this field may contain special value all or - a list of specific and wildcard architectures separated by + package, this field may contain the special value all + or a list of specific and wildcard architectures separated by spaces. If all appears, that value must be the entire contents of the field. Most packages will use either any or all. Specifying a specific @@ -2758,6 +2766,23 @@ Package: libc6 portable instead.

+

+ Specifying a list of architecture wildcards indicates that + the source will build an architecture-dependent package on + the union of the lists of architectures from the expansion + of each specified architecture wildcard, and will only + work correctly on the architectures in the union of the + lists. + Use of architecture wildcards other than all is for + a minority of cases where the program is not portable and + should not be used for most packages. Wildcards are not + expanded into a list of known architectures before comparing + to the build architecutre. Instead, the build architecture + is matched against any wildcards and this package is built + if any wildcard matches. + +

+

In the source package control file .dsc, this field may contain either the special value any or a @@ -2789,44 +2814,24 @@ Package: libc6

- Specifying a list of architectures indicates that the source - will build an architecture-dependent package, and will only - 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. -

- -

- Specifying a list of architecture wildcards indicates that - the source will build an architecture-dependent package on - the union of the lists of architectures from the expansion - of each specified architecture wildcard, and will only - work correctly on the architectures in the union of the - lists. - As mentioned in the footnote for specifying a list of - architectures, this is for a minority of cases where the - program is not portable. It should not be used for most - packages. Wildcards are not expanded into a list of known - architectures before comparing to the build architecutre. - Instead, the build architecture is matched against any - wildcards and this package is built if any wildcard - matches. - - If the source package also builds at least one - architecture-independent package, all will also be - included in the list. + Specifying a list of architectures or architecture wildcards + indicates that the source will build an architecture-dependent + package, and will only work correctly on the listed or + matching architectures. If the source package also builds at + least one architecture-independent package, all will + also be included in the list.

In a .changes file, the Architecture - 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 + 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. all will be present if any architecture-independent packages are being - uploaded. any may never occur in the - Architecture field in the .changes - file. + uploaded. Architecture wildcards such as any may + never occur in the Architecture field in + the .changes file.

@@ -4280,6 +4285,21 @@ Build-Depends: foo [!i386] | bar [!amd64] bar on all other architectures.

+

+ All fields that specify build-time relationships may also be + restricted to a certain set of architectures using architecture + wildcards. The syntax for declaring such restrictions is the + same as declaring restrictions using a certain set of + architectures without architecture wildcards. For example: + +Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any] + + is equivalent to foo on architectures using the Linux + kernel and any cpu, bar on architectures using any + kernel and an i386 cpu, and baz on any architecture + using a kernel other than Linux. +

+

Note that the binary package relationship fields such as Depends appear in one of the binary package @@ -4288,23 +4308,6 @@ Build-Depends: foo [!i386] | bar [!amd64] source package section of the control file (which is the first section).

-

- All fields that specify build-time relationships - (Build-Depends, Build-Depends-Indep, - Build-Conflicts and Build-Conflicts-Indep) may also - be restricted to a certain set of architectures using architecture - wildcards. The syntax for declaring such restrictions is the same as - declaring restrictions using a certain set of architectures without - architecture wildcards. - For example: - -Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any] - - is equivalent to foo on architectures using the - Linux kernel and any cpu, bar on architectures - using any kernel and an i386 cpu, and baz on - on any architecture using a kernel other than Linux. -

@@ -5895,7 +5898,7 @@ rmdir /usr/local/share/emacs 2>/dev/null || true

- 1000-29999: + 1000-59999:

Dynamically allocated user accounts. By default @@ -5906,11 +5909,6 @@ rmdir /usr/local/share/emacs 2>/dev/null || true

- 30000-59999: - -

Reserved.

- - 60000-64999:

@@ -7804,15 +7802,12 @@ endscript security policy by changing the permissions on a binary: they can do this by using dpkg-statoverride, as described below. - Ordinary files installed by dpkg (as - opposed to conffiles and other similar objects) - normally have their permissions reset to the distributed - permissions when the package is reinstalled. However, - the use of dpkg-statoverride overrides this - default behavior. If you use this method, you should - remember to describe dpkg-statoverride in - the package documentation; being a relatively new - addition to Debian, it is probably not yet well-known. + Ordinary files installed by dpkg (as + opposed to conffiles and other similar objects) + normally have their permissions reset to the distributed + permissions when the package is reinstalled. However, + the use of dpkg-statoverride overrides this + default behavior. Another method you should consider is to create a group for people allowed to use the program(s) and make any setuid @@ -8006,15 +8001,16 @@ done Architecture Wildcards

- A package may specify an architecture wildcard. Architecture - wildcards are in the format os-any and - any-cpu. + A package may specify an architecture wildcard. Architecture + wildcards are in the format any (which matches every + architecture), os-any, or + any-cpu. Internally, the package system normalizes the GNU triplets and the Debian arches into Debian arch triplets (which are kind of inverted GNU triplets), with the first component of the - triplet representing the libc in use. When matching two - Debian arch triplets, whenever an any is found it - matches with anything on the other side, like in: + triplet representing the libc and ABI in use. When matching + two Debian arch triplets, whenever an any is found + it matches with anything on the other side, like in: gnu-linux-i386 is matched by gnu-linux-any gnu-kfreebsd-amd64 is matched by any-any-amd64 @@ -9177,7 +9173,7 @@ END-INFO-DIR-ENTRY

Every package must be accompanied by a verbatim copy of its - copyright and distribution license in the file + copyright information and distribution license in the file /usr/share/doc/package/copyright. This file must neither be compressed nor be a symbolic link.

@@ -10057,120 +10053,6 @@ END-INFO-DIR-ENTRY

- - - debian/changelog - -

- See . -

- - Defining alternative changelog formats - - -

- It is possible to use a different format to the standard - one, by providing a parser for the format you wish to - use. -

- -

- In order to have dpkg-parsechangelog run your - parser, you must include a line within the last 40 lines - of your file matching the Perl regular expression: - \schangelog-format:\s+([0-9a-z]+)\W The part in - parentheses should be the name of the format. For - example, you might say: - - @@@ changelog-format: joebloggs @@@ - - Changelog format names are non-empty strings of alphanumerics. -

- -

- If such a line exists then dpkg-parsechangelog - will look for the parser as - /usr/lib/dpkg/parsechangelog/format-name - or - /usr/local/lib/dpkg/parsechangelog/format-name; - it is an error for it not to find it, or for it not to - be an executable program. The default changelog format - is dpkg, and a parser for it is provided with - the dpkg package. -

- -

- The parser will be invoked with the changelog open on - standard input at the start of the file. It should read - the file (it may seek if it wishes) to determine the - information required and return the parsed information - to standard output in the form of a series of control - fields in the standard format. By default it should - return information about only the most recent version in - the changelog; it should accept a - -vversion option to return changes - information from all versions present strictly - after version, and it should then be an - error for version not to be present in the - changelog. -

- -

- The fields are: - - Source - Version (mandatory) - Distribution (mandatory) - Urgency (mandatory) - Maintainer (mandatory) - Date - Changes (mandatory) - -

- -

- If several versions are being returned (due to the use - of -v), the urgency value should be of the - highest urgency code listed at the start of any of the - versions requested followed by the concatenated - (space-separated) comments from all the versions - requested; the maintainer, version, distribution and - date should always be from the most recent version. -

- -

- For the format of the Changes field see - . -

- -

- If the changelog format which is being parsed always or - almost always leaves a blank line between individual - change notes these blank lines should be stripped out, - so as to make the resulting output compact. -

- -

- If the changelog format does not contain date or package - name information this information should be omitted from - the output. The parser should not attempt to synthesize - it or find it from other sources. -

- -

- If the changelog does not have the expected format the - parser should exit with a nonzero exit status, rather - than trying to muddle through and possibly generating - incorrect output. -

- -

- A changelog parser may not interact with the user at - all. -

- - - debian/substvars and variable substitutions