]> git.donarmstrong.com Git - debian/debian-policy.git/commitdiff
Added a note about the forthcoming dpkg-shlibdeps. Added a note about the new X beastie.
authorManoj Srivastava <srivasta@debian.org>
Thu, 16 Jun 2005 05:08:21 +0000 (05:08 +0000)
committerManoj Srivastava <srivasta@debian.org>
Thu, 16 Jun 2005 05:08:21 +0000 (05:08 +0000)
Author: srivasta
Date: 2000/07/30 22:47:15
Added a note about the forthcoming dpkg-shlibdeps. Added a note about the new X beastie.

git-archimport-id: srivasta@debian.org--etch/debian-policy--devel--3.0--patch-59

debian/changelog
packaging.sgml
policy.sgml
upgrading-checklist.html

index 6314ed4418482f3daf3e549f4016ab19cf8ab8a4..1df07263167ac6d4ddaaf71b13f05aa6aba7c808 100644 (file)
@@ -1,12 +1,21 @@
 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
@@ -22,21 +31,12 @@ debian-policy (3.2.0.0) unstable; urgency=low
   * [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:
@@ -48,8 +48,10 @@ debian-policy (3.2.0.0) unstable; urgency=low
   * 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
 
index 094a62fffbf41ab796af7e9dd6e1f5fb65c80164..f5fd280379e575b338e6c971c03051152c11cd5c 100644 (file)
          </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>       
index 28a3399c89c1ad4a1cb5335b6dca62ff6bf9a33e..6d14beb6e326e60f6f83c8d64856f51c33d0d963 100644 (file)
        <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>
index 756429448f70a158ee422ad8ef9154a123d74d33..2647c09cadbee3b17ac9bc8be5a0a6d816e2918d 100644 (file)
@@ -76,9 +76,6 @@ Manual.
      - 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