X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;f=policy.sgml;h=83d42a9f38b15210852ace0932ec427480d4dc3f;hb=ba95502cd0565d860bf41a70e5dddacd93d4dad4;hp=dc4553cfd04d0af89d238c44e93e950ae6c0f710;hpb=89ad8aaab13906a24d1482fc54154bb2b3f7f1e3;p=debian%2Fdebian-policy.git diff --git a/policy.sgml b/policy.sgml index dc4553c..83d42a9 100644 --- a/policy.sgml +++ b/policy.sgml @@ -878,36 +878,30 @@
In general, Debian packages should use the same version - numbers as the upstream sources. -
- -
- However, in some cases where the upstream version number is
- based on a date (e.g., a development "snapshot" release) the
- package management system cannot handle these version
- numbers without epochs. For example, dpkg will consider
- "96May01" to be greater than "96Dec24".
+ numbers as the upstream sources. However, upstream version
+ numbers based on some date formats (sometimes used for
+ development or "snapshot" releases) will not be ordered
+ correctly by the package management software. For
+ example,
To prevent having to use epochs for every new upstream - version, the date based portion of the version number - should be changed to the following format in such cases: - "19960501", "19961224". It is up to the maintainer whether - they want to bother the upstream maintainer to change - the version numbers upstream, too. -
- -- Note that other version formats based on dates which are - parsed correctly by the package management system should - not be changed. + version, the date-based portion of any upstream version number + should be given in a way that sorts correctly: four-digit year + first, followed by a two-digit numeric month, followed by a + two-digit numeric date, possibly with punctuation between the + components.
- Native Debian packages (i.e., packages which have been - written especially for Debian) whose version numbers include - dates should always use the "YYYYMMDD" format. + Native Debian packages (i.e., packages which have been written + especially for Debian) whose version numbers include dates + should also follow these rules. If punctuation is desired + between the date components, remember that hyphen (-) + cannot be used in native package versions. Period + (.) is normally a good choice.
@@ -1642,7 +1636,15 @@ The maintainer name and email address used in the changelog should be the details of the person uploading this version. They are not necessarily those of the - usual package maintainer. The information here will be + usual package maintainer
- When
@@ -5081,7 +5083,7 @@ Replaces: mail-transport-agent
There is no Build-Depends-Arch; this role is essentially met with Build-Depends. Anyone building the - build-indep and binary-indep targets is + build-indep and binary-indep targets is assumed to be building the whole package, and therefore installation of all build dependencies is required.
@@ -5130,55 +5132,134 @@ Replaces: mail-transport-agent- Packages involving shared libraries should be split up into - several binary packages. This section mostly deals with how - this separation is to be accomplished; rules for files within - the shared library packages are in instead. + This section deals only with public shared libraries: shared + libraries that are placed in directories searched by the dynamic + linker by default or which are intended to be linked against + normally and possibly used by other, independent packages. Shared + libraries that are internal to a particular package or that are + only loaded as dynamic modules are not covered by this section and + are not subject to its requirements.
-
+ A shared library is identified by the SONAME attribute
+ stored in its dynamic section. When a binary is linked against a
+ shared library, the SONAME of the shared library is
+ recorded in the binary's NEEDED section so that the
+ dynamic linker knows that library must be loaded at runtime. The
+ shared library file's full name (which usually contains additional
+ version information not needed in the SONAME) is
+ therefore normally not referenced directly. Instead, the shared
+ library is loaded by its SONAME, which exists on the file
+ system as a symlink pointing to the full name of the shared
+ library. This symlink must be provided by the
+ package. describes how to do this.
+
- The run-time shared library needs to be placed in a package
- whose name changes whenever the shared object version
- changes.
- Since it is common place to install several versions of a
- package that just provides shared libraries, it is a
- good idea that the library package should not
- contain any extraneous non-versioned files, unless they
- happen to be in versioned directories.
+ Shared libraries are normally split into several binary packages. + The SONAME symlink is installed by the runtime shared + library package, and the bare .so symlink is installed in + the development package since it's only used when linking binaries + or shared libraries. However, there are some exceptions for + unusual shared libraries or for shared libraries that are also + loaded as dynamic modules by other programs.
- If you have several shared libraries built from the same - source tree you may lump them all together into a single - shared library package, provided that you change all of - their sonames at once (so that you don't get filename - clashes if you try to install different versions of the - combined shared libraries package). + This section is primarily concerned with how the separation of + shared libraries into multiple packages should be done and how + dependencies on and between shared library binary packages are + managed in Debian. should be read in + conjunction with this section and contains additional rules for + the files contained in the shared library packages.
+
+ The run-time shared library must be placed in a package
+ whose name changes whenever the SONAME of the shared
+ library changes. This allows several versions of the shared
+ library to be installed at the same time, allowing installation
+ of the new version of the shared library without immediately
+ breaking binaries that depend on the old version. Normally, the
+ run-time shared library and its SONAME symlink should
+ be placed in a package named
+
+ If you have several shared libraries built from the same source + tree, you may lump them all together into a single shared + library package provided that all of their SONAMEs will + always change together. Be aware that this is not normally the + case, and if the SONAMEs do not change together, + upgrading such a merged shared library package will be + unnecessarily difficult because of file conflicts with the old + version of the package. When in doubt, always split shared + library packages so that each binary package installs a single + shared library. +
+ ++ Every time the shared library ABI changes in a way that may + break binaries linked against older versions of the shared + library, the SONAME of the library and the + corresponding name for the binary package containing the runtime + shared library should change. Normally, this means + the SONAME should change any time an interface is + removed from the shared library or the signature of an interface + (the number of parameters or the types of parameters that it + takes, for example) is changed. This practice is vital to + allowing clean upgrades from older versions of the package and + clean transitions between the old ABI and new ABI without having + to upgrade every affected package simultaneously. +
+ +
+ The SONAME and binary package name need not, and indeed
+ normally should not, change if new interfaces are added but none
+ are removed or changed, since this will not break binaries
+ linked against the old shared library. Correct versioning of
+ dependencies on the newer shared library by binaries that use
+ the new interfaces is handled via
+ the
The package should install the shared libraries under
their normal names. For example, the
- The run-time library package should include the symbolic link that
-
+ If the package provides Ada Library Information
+ (
- Log files must be rotated occasionally so that they don't
- grow indefinitely; the best way to do this is to drop a log
- rotation configuration file into the directory
-
The traditional approach to log files has been to set up
ad hoc log rotation schemes using simple shell
@@ -7957,17 +8061,20 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq
section="8">):
@@ -7979,7 +8086,7 @@ endscript
@@ -8020,6 +8127,12 @@ endscript
+
+ Control information files should be owned by root:root
+ and either mode 644 (for most files) or mode 755 (for
+ executables such as
Setuid and setgid executables should be mode 4755 or 2755 @@ -8306,10 +8419,14 @@ done
These two files are managed through the
@@ -8358,11 +8475,13 @@ done
@@ -8729,6 +8850,9 @@ name ["syshostname"]:
configuration, add 10 points; otherwise add none.
+ That alternative should have a slave alternative
+ for