debian-policy (3.2.0.0) unstable; urgency=low
* Fixed bugs in debian-policy package:
+ * We have had doc-base support for a while now. closes: Bug#15709
+ * packaging manual: Added additional clarification on dpkg
+ behaviour. closes: Bug#17369
* [PROPOSAL] Do not make hardlinks to conffiles closes: Bug#22935
- * [OLD PROPOSAL] debian-policy has an unclear statement on dependancies
- and priorities closes: Bug#39398
+ * [PROPOSED]: clarification needed about diversions.
+ fixed usage for dpkg-divert closes: Bug#29522
+ * [OLD PROPOSAL] debian-policy has an unclear statement
+ on dependancies and priorities closes: Bug#39398
* [ACCEPTED 10/26/99] changelog.html.gz sanitization. closes: Bug#40934
* [AMENDED 07/09/1999] policy on -g, a proposal closes: Bug#43787
+ * Fixed missing </chapt> tag. closes: Bug#51091
* Correct typo in section 2.3.5 closes: Bug#52225
+ * Documented that the library before the symlink hack
+ (which dependend on file system specific kinks to work)
+ is no longer required by newer versions of dpkg. closes: Bug#53405
* [ACCEPTED 02/01/2000] policy for usage of "xserver"
alternative closes: Bug#53755
* [ACCEPTED 02/01/2000] additions to virtual package
* [ACCEPTED 02/01/2000] applying the FHS to packages
that use X closes: Bug#53762
* [ACCEPTED 02/01/2000] policy for X font packages closes: Bug#53763
- * Moved the documents into the Debian/ section, since that is where they
- belong, really. closes: Bug#54777
+ * Moved the documents into the Debian/ section, since
+ that is where they belong, really. closes: Bug#54777
* Fixed the ftp location in the manuals. closes: Bug#56407
* Fixed missing urlname entity in the sgml docs (where
was it defined before anyway?) closes: Bug#56692
* Fixed bugs in packaging-manual package:
- * We have had doc-base support for a while now. closes: Bug#15709
- * packaging manual: Added additional clarification on dpkg
- behaviour. closes: Bug#17369
- * [PROPOSED]: clarification needed about diversions.
- fixed usage for dpkg-divert closes: Bug#29522
- * Fixed missing </chapt> tag. closes: Bug#51091
- * Documented that the library before the symlink hack (which dependend
- on file system specific kinks to work) is no longer required by newer
- versions of dpkg. closes: Bug#53405
* Fixed typo where dpkg-genchanges was used instead of
dpkg-gencontrol. closes: Bug#58771
* Other changes:
* Added FHS details to copyright file
* Updaed the upgrade checklist. Minor changes to the ./debian/rules
file.
+ * Added footnotes in the packaging manual warning about the upcoming
+ dpkg-shlibdeps change as in Bug#55730
- -- Manoj Srivastava <srivasta@debian.org> Sun, 30 Jul 2000 16:36:34 -0500
+ -- Manoj Srivastava <srivasta@debian.org> Sun, 30 Jul 2000 17:43:02 -0500
debian-policy (3.1.1.3) unstable; urgency=low
</p>
<p>
- Its arguments are executables and libraries
+ Its arguments are executables.
<footnote>
+ <p>
+ In a forthcoming dpkg version,
+ <prgn>dpkg-shlibdeps</prgn> would be required to be
+ called on shared libraries as well.
+ </p>
<p>
They may be specified either in the locations in the
source tree where they are created or in the locations
work?
</heading>
<p>
- <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.
+ <prgn>dpkg-shlibdeps</prgn>
+ determines the shared libraries directly
+ <footnote>
+ <p>
+ Currently, it calls <prgn>ldd</prgn>, but in a
+ forthcoming version it shall call <prgn>objdump</prgn>
+ to to this. This however changes will need a couple of
+ changes in the way that packages are build.
+ </p>
+ <p>
+ Suppose 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>. Using <prgn>ldd</prgn>
+ lists all the libraries, used direcly and indirectly;
+ but <prgn>objdump</prgn> only lists the directly
+ linked libraries. A package only needs to depend on
+ the libraries it is directly linked to, since the
+ dependencies for those libraries should automatically
+ pull in the other libraries.</p>
+
+ <p>
+ This change does mean a change in the way packages are
+ build though: currently dpkg-shlibdeps is only run on
+ binaries. But since we will now depend on the
+ libraries to depend on the libraries they need the
+ packages containing those libraries will need to run
+ dpkg-shlibdeps on the libraries.
+ </p>
+ <p>
+ A good example where this would help us is the current
+ mess with multiple version of the mesa library. With
+ the ldd-based system every package that uses mesa need
+ to add a dependency on svgalib|svgalib-dummy in order
+ to handle the glide mesa variant. With an
+ objdump-based system this isn't necessary anymore and
+ would have saved everyone a lot of work.
+ </p>
+ <p>
+ Another example: we could update libimlib with a new
+ version that supports a new graphics format called
+ dgf. If we use the old ldd method every package that
+ uses libimlib would need to be recompiled so it would
+ also depend on libdgf or it wouldn't run due to
+ missing symbols. However with the new system packages
+ using libimlib can depend on libimlib itself having
+ the dependency on libgdh and wouldn't need to be
+ updated.
+ </p>
+ </footnote>
+ used by the compiled binaries (and libraries, in a version
+ of <prgn>dpkg-shlibdeps</prgn> coming soon) passed through
+ on its command line.
</p>
<p>
<p>
Some programs can be configured with or without support for the X
Window System. Typically, binaries produced with support for X
- will need the X shared libraries to run.
+ will need the X shared libraries to run.<footnote>
+ <p>
+ <strong>NOTE</strong> The forthcoming major X Window
+ System release shall probably change this
+ drastically.
+ </p>
+ </footnote>
</p>
<p>
In a nutshell, X servers that interface directly with
the display and input hardware or via another subsystem
(e.g., GGI) should provide xserver. Things like Xvfb,
- Xnest, and Xprt should not.
+ Xnest, and Xprt should not. <strong>NOTE</strong> The
+ forthcoming major X Window System release shall probably
+ change this drastically.
</p>
</footnote>
</p>
- Noted that newer dpkg versions do not require extreme care in
always creating theshared lib before the symlink, so the unpack
order be correct.
- - Note that the newer dpkg-shlibdeps use objdump to determine the
- shared libraries directly, and now should be run on both
- executables and libraries.
3.1.1.0 Nov 99