<name>Maintainer: Manoj Srivastava </name>
<email>srivasta@debian.org</email>
</author>
+ <author>
+ <name>Maintainer: Julian Gilbey </name>
+ <email>J.D.Gilbey@qmw.ac.uk</email>
+ </author>
<author>
<name>Maintainer: The Debian Policy group </name>
<email>debian-policy@lists.debian.org</email>
<abstract>
This manual describes the technical aspects of creating Debian
- binary and source packages. It also documents the interface
- between <prgn>dselect</prgn> and its access method scripts.
- It does not deal with the Debian Project policy requirements,
- and it assumes familiarity with <prgn>dpkg</prgn>'s functions
- from the system administrator's perspective. This
- package itself is maintained by a group of maintainers
- that have no editorial powers. At the moment, the list of
- maintainers is:
+ binary and source packages. It does not deal with the Debian
+ Project policy requirements, and it assumes familiarity with
+ <prgn>dpkg</prgn>'s functions from the system administrator's
+ perspective. This package itself is maintained by a group of
+ maintainers that have no editorial powers. At the moment, the
+ list of maintainers is:
<enumlist>
<item>
<p>Michael Alan Dorman <email>mdorman@debian.org</email></p>
<item>
<p>Philip Hands <email>phil@hands.com</email></p>
</item>
+ <item>
+ <p>Julian Gilbey <email>J.D.Gilbey@qmw.ac.uk</email></p>
+ </item>
<item>
<p>Manoj Srivastava <email>srivasta@debian.org</email></p>
</item>
</footnote>
</p>
</sect>
-
+ </chapt>
+
<chapt id="sourcepkg">
<heading>Source packages</heading>
</p>
<p>
- Its arguments are executables
+ Its arguments are executables and libraries
<footnote>
<p>
They may be specified either in the locations in the
</p>
<p>
- If some of the executable(s) shared libraries should only
+ If some of the found shared libraries should only
warrant a <tt>Recommends</tt> or <tt>Suggests</tt>, or if
some warrant a <tt>Pre-Depends</tt>, this can be achieved
by using the <tt>-d<var>dependency-field</var></tt> option
the value from a <tt>.deb</tt> file if they have no other
information; a value listed in a <tt>Packages</tt> file
will always take precedence. By default
- <prgn>dpkg-genchanges</prgn> does not include the section
+ <prgn>dpkg-gencontrol</prgn> does not include the section
and priority in the control file of a binary package - use
the <tt>-isp</tt>, <tt>-is</tt> or <tt>-ip</tt> options to
achieve this effect.</p>
<p>
If you need to compare version numbers in a script, you may use
<tt>dpkg --compare-versions ...</tt>. Type <tt>dpkg
- --help</tt> --> --for details on arguments.
+ --help</tt> for details on arguments.
</p>
<sect>
<footnote>
<p>
Part of the problem is due to what is arguably a
- bug in <prgn>dpkg</prgn> .
+ bug in <prgn>dpkg</prgn>.
</p>
</footnote>
</p>
</p>
<p>
- If one package is to be installed, the other must be removed first -
- if the package being installed is marked as replacing (<ref
- id="replaces">) the one on the system, or the one on the system is
- marked as deselected, or both packages are marked
- <tt>Essential</tt>, then <prgn>dpkg</prgn> will
- automatically remove the package which is causing the
- conflict, otherwise it will halt the installation of the new
- package with an error.
+ If one package is to be installed, the other must be removed
+ first - if the package being installed is marked as
+ replacing (<ref id="replaces">) the one on the system, or
+ the one on the system is marked as deselected, or both
+ packages are marked <tt>Essential</tt>, then
+ <prgn>dpkg</prgn> will automatically remove the package
+ which is causing the conflict, otherwise it will halt the
+ installation of the new package with an error. This
+ mechanism specifically doesn't work when the installed
+ package is <tt>Essential</tt>, but the new package is not.
</p>
<p>
<sect><heading>Relationships between source and binary packages -
<tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>,
<tt>Build-Conflicts</tt>, <tt>Build-Conflicts-Indep</tt>
- </heading>
+ </heading>
<p>
A source package may declare a dependency or a conflict on a
when one of the targets in <tt>debian/rules</tt> that the
particular field applies to is invoked.
- <taglist>
- <tag><tt>Build-Depends</tt>, <tt>Build-Conflicts</tt></tag>
- <item>
- <p>
- The <tt>Build-Depends</tt> and <tt>Build-Conflicts</tt> fields apply
- to the targets
- <tt>build</tt>, <tt>binary</tt>, <tt>binary-arch</tt>
- and <tt>binary-indep</tt>.
- </p>
- </item>
- <tag><tt>Build-Depends-Indep</tt>, <tt>Build-Conflicts-Indep</tt></tag>
- <item>
- <p>
- The <tt>Build-Depends-Indep</tt> and
- <tt>Build-Conflicts-Indep</tt> fields apply to the
- targets <tt>binary</tt> and <tt>binary-indep</tt>.
- </p>
- </item>
- </taglist>
+ <taglist>
+ <tag><tt>Build-Depends</tt>, <tt>Build-Conflicts</tt></tag>
+ <item>
+ <p>
+ The <tt>Build-Depends</tt> and
+ <tt>Build-Conflicts</tt> fields apply to the targets
+ <tt>build</tt>, <tt>binary</tt>, <tt>binary-arch</tt>
+ and <tt>binary-indep</tt>.
+ </p>
+ </item>
+ <tag><tt>Build-Depends-Indep</tt>, <tt>Build-Conflicts-Indep</tt></tag>
+ <item>
+ <p>
+ The <tt>Build-Depends-Indep</tt> and
+ <tt>Build-Conflicts-Indep</tt> fields apply to the
+ targets <tt>binary</tt> and <tt>binary-indep</tt>.
+ </p>
+ </item>
+ </taglist>
- </p>
+ </p>
- </sect>
+ </sect>
+ </chapt>
- </chapt>
<chapt id="conffiles"><heading>Configuration file handling
</heading>
supposing that a <prgn>smailwrapper</prgn> package wishes to
install a wrapper around <tt>/usr/sbin/smail</tt>:
<example>
- if [ install = "$1" ]; then
+ if [ install = "$1" -o upgrade = "$1" ]; then
dpkg-divert --package smailwrapper --add --rename \
--divert /usr/sbin/smail.real /usr/sbin/smail
fi
<tt>libgdbm.so.1.7.3</tt>. This is needed so that
<prgn>ld.so</prgn> can find the library in between the time
<prgn>dpkg</prgn> installs it and <prgn>ldconfig</prgn> is run
- in the <prgn>postinst</prgn> script. Futhermore, and <em>this
- is very important</em>, the library must be placed before the
- symlink pointing to it in the <tt>.deb</tt> file. This is so
- that by the time <prgn>dpkg</prgn> comes to install the
- symlink (overwriting the previous symlink pointing at an older
- version of the library) the new shared library is already in
- place. Currently the way to ensure the ordering is done
- properly is to install the library in the appropriate
- <tt>debian/tmp/.../lib</tt> directory before creating the
- symlink, by putting the commands in the <tt>debian/rules</tt>
- in the appropriate order. Whether this has been done
- correctly can be checked by performing an <tt>ls -f</tt>.
+ in the <prgn>postinst</prgn> script. Futhermore, older
+ versions of the package management system required the library
+ must be placed before the symlink pointing to it in the
+ <tt>.deb</tt> file. This is so that by the time
+ <prgn>dpkg</prgn> comes to install the symlink (overwriting
+ the previous symlink pointing at an older version of the
+ library) the new shared library is already in place.
+ Unfortunately, this was not not always possible, since it
+ highly depends on the behaviour of the filesystem. Some
+ filesystems (such as reisefs) will reorder the files so it
+ doesn't matter in what order you create them. In newer
+ versions of <prgn>dpkg</prgn>, this is handled automatically.
</p>
<!--
<sect1><heading><em>How</em> does <prgn>dpkg-shlibdeps</prgn>
work?
</heading>
-
<p>
- <prgn>dpkg-shlibdeps</prgn> calls <prgn>ldd</prgn> to
- determine the shared libraries used by the compiled
- binaries passed through its command line.
+ <prgn>dpkg-shlibdeps</prgn> calls <prgn>objdump</prgn> to
+ determine the shared libraries directly
+ <footnote> a binary <tt>foo</tt> directly use a library
+ <tt>libbar</tt> if it is linked with that library. Other
+ libraries that are needed by <tt>libbar</tt> are linked
+ indirectly to <tt>foo</tt>, and the dynamic linker will load
+ the automatically when it loads <tt>libbar</tt>.
+ </footnote> used by the compiled binaries and libraries
+ passed through its command line.
</p>
<p>
</book>
</debiandoc>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-