<p>
Changes in the Debian version of the package should be
briefly explained in the Debian changelog file
- <file>debian/changelog</file>. This includes modifications
+ <file>debian/changelog</file>.<footnote>
+ <p>
+ Mistakes in changelogs are usually best rectified by
+ making a new changelog entry rather than "rewriting
+ history" by editing old changelog entries.
+ </p>
+ </footnote>
+ This includes modifications
made in the Debian package compared to the upstream one
as well as other changes and updates to the package.
<footnote>
</p>
<p>
- Mistakes in changelogs are usually best rectified by making
- a new changelog entry rather than "rewriting history" by
- editing old changelog entries.
+
</p>
<p>
<example compact="compact">
<var>new-preinst</var> upgrade <var>old-version</var>
</example>
+
+ <example>
+<var>new-postrm</var> abort-upgrade <var>old-version</var>
+ </example>
+ If that too fails, then
+ <example>
+<var>old-postinst</var> abort-upgrade <var>old-version</var>
+ </example>
+ is called.
</item>
<item>
Otherwise, if the package had some configuration
<example compact="compact">
<var>new-preinst</var> install <var>old-version</var>
</example>
+ Error unwind:
+ <example>
+<var>new-postrm</var> abort-install <var>old-version</var>
+ </example>
</item>
<item>
Otherwise (i.e., the package was completely purged):
<example compact="compact">
<var>new-preinst</var> install
- </example>
- Error unwind actions, respectively:
- <example compact="compact">
-<var>new-postrm</var> abort-upgrade <var>old-version</var>
-<var>new-postrm</var> abort-install <var>old-version</var>
+ </example>
+ Error unwind:
+ <example compact="compact">
<var>new-postrm</var> abort-install
- </example>
+ </example>
</item>
- </enumlist>
+ </enumlist>
</item>
<item>
<heading>Run-time shared libraries</heading>
<p>
- The run-time shared library needs to be placed in a package called
- <package><var>libraryname</var><var>soversion</var></package>, where
- <file><var>soversion</var></file> is the version number in the
- soname of the shared library<footnote>
+ The run-time shared library needs to be placed in a package
+ whose name changes whenever the shared object version
+ changes.<footnote>
+ <p>
+ Since it is common place to install several versions of a
+ package that just provides shared libraries, it is a
+ good idea that that the library package should not
+ contain any extraneous non-versioned files, unless they
+ happen to be in versioned directories.</p>
+ </footnote>
+ The most common mechanism is to place it in a package
+ called
+ <package><var>libraryname</var><var>soversion</var></package>,
+ where <file><var>soversion</var></file> is the version number
+ in the soname of the shared library<footnote>
The soname is the shared object name: it's the thing
that has to match exactly between building an executable
and running it for the dynamic linker to be able run the
<package><var>libraryname</var>-<var>soversion</var>-dev</package>
instead.
</p>
-
<p>
If you have several shared libraries built from the same
source tree you may lump them all together into a single
<action></example> in their <prgn>postinst</prgn>
and <prgn>prerm</prgn> scripts to:
<example compact="compact">
- if command -v invoke-rc.d >/dev/null 2>&1; then
+ if which invoke-rc.d >/dev/null 2>&1; then
invoke-rc.d <var>package</var> <action>
else
/etc/init.d/<var>package</var> <action>
</p>
<p>
- Here is a list of overall rules that you should use when you
- create output messages. They can be useful if you have a
- non-standard message that is not covered specifically in the
- sections below.
+ Here is a list of overall rules that should be used for
+ messages generated by <file>/etc/init.d</file> scripts.
</p>
<p>
<list>
<item>
- Every message should fit in one line (fewer than 80
+ The message should fit in one line (fewer than 80
characters), start with a capital letter and end with
a period (<tt>.</tt>) and line feed (<tt>"\n"</tt>).
</item>
<item>
- If you want to express that the computer is working on
- something (that is, performing a specific task, not
- starting or stopping a program), we use an "ellipsis"
- (three dots: <tt>...</tt>). Note that we don't insert
- spaces before or after the dots. If the task has been
- completed we write <tt>done.</tt> and a line feed.
+ If the script is performing some time consuming task in
+ the background (not merely starting or stopping a
+ program, for instance), an ellipsis (three dots:
+ <tt>...</tt>) should be output to the screen, with no
+ leading or tailing whitespace or line feeds.
</item>
<item>
- Design your messages as if the computer is telling you
- what it is doing (let it be polite :-), but don't
- mention "it" directly. For example, if you think of
- saying
+ The messages should appear as if the computer is telling
+ the user what it is doing (politely :-), but should not
+ mention "it" directly. For example, instead of:
<example compact="compact">
I'm starting network daemons: nfsd mountd.
</example>
- just say
+ the message should say
<example compact="compact">
Starting network daemons: nfsd mountd.
</example>
</p>
<p>
- There are standard message formats for the following
- situations. They should be used by the <tt>init.d</tt>
- scripts.
+ <tt>init.d</tt> script should use the following standard
+ message formats for the situations enumerated below.
</p>
<p>
<p>When daemons are started</p>
<p>
- If your script starts one or more daemons, the output
+ If the script starts one or more daemons, the output
should look like this (a single line, no leading
spaces):
<example compact="compact">
start-stop-daemon --start --quiet --exec /usr/sbin/lpd
echo "."
</example>
- in the script. If you have more than one daemon to
- start, you should do the following:
+ in the script. If there are more than one daemon to
+ start, the output should look like this:
<example compact="compact">
echo -n "Starting remote file system services:"
echo -n " nfsd"; start-stop-daemon --start --quiet nfsd
echo -n " ugidd"; start-stop-daemon --start --quiet ugidd
echo "."
</example>
- This makes it possible for the user to see what takes
- so long and when the final daemon has been started.
- You should be careful where to put spaces: in the
- example above the system administrator can easily
- comment out a line if they don't want to start a
- specific daemon, while the displayed message still
+ This makes it possible for the user to see what is
+ happening and when the final daemon has been started.
+ Care should be taken in the placement of white spaces:
+ in the example above the system administrators can
+ easily comment out a line if they don't want to start
+ a specific daemon, while the displayed message still
looks good.
</p>
</item>
projects / debian / debian-policy.git / blobdiff