r1724: releasing version 4.2.24

diff --git a/debian/changelog b/debian/changelog
index 0afb4fa03ec4393bccdf0401b1c8892ac684240d..e9809d2854647ef1de57169f16b61502542bd8b1 100644 (file)
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,8 @@
-debhelper (4.2.24) UNRELEASED; urgency=low
+debhelper (4.2.24) unstable; urgency=low
 
   * Spanish man page updates.
+  * Improve the documentation of dh_makeshlibs behavior in v4 mode.
+    Closes: #280676
 
  -- Joey Hess <joeyh@debian.org>  Sat, 30 Oct 2004 18:52:00 -0400
 

diff --git a/dh_makeshlibs b/dh_makeshlibs
index 1d57b01eb0842c603d6c62a09abc131a96c900b2..5a0327905ec2470fdb02746084bd0b3df304b338 100755 (executable)
--- a/dh_makeshlibs
+++ b/dh_makeshlibs
@@ -40,16 +40,20 @@ By default, the shlibs file generated by this program does not make packages
 depend on any particular version of the package containing the shared
 library. It may be necessary for you to add some version dependancy
 information to the shlibs file. If -V is specified with no dependancy
-information, the current version of the package is plugged into a
-dependancy that looks like "packagename (>= packageversion)". If -V is
-specified with parameters, the parameters can be used to specify the exact
-dependancy information needed (be sure to include the package name).
+information, the current upstream version of the package is plugged into a
+dependancy that looks like "packagename (>= packageversion)". Note that in
+debhelper compatability levels before v4, the debian part of the package
+version number is also included. If -V is specified with parameters, the
+parameters can be used to specify the exact dependancy information needed
+(be sure to include the package name).
 
 Beware of using -V without any parameters; this is a conservative setting
 that always ensures that other packages' shared library dependencies are at
-least as tight as they need to be, so that if the maintainer screws up then
-they won't break. The flip side is that packages might end up with
-dependencies that are too tight and so find it harder to be upgraded.
+least as tight as they need to be (unless your library is prone to changing
+ABI without updating the upstream version number), so that if the
+maintainer screws up then they won't break. The flip side is that packages
+might end up with dependencies that are too tight and so find it harder to
+be upgraded.
 
 =item B<-n>, B<--noscripts>
 
@@ -64,23 +68,27 @@ from being treated as shared libraries.
 
 =head1 EXAMPLES
 
- dh_makeshlibs
+=over 4
+
+=item dh_makeshlibs
 
 Assuming this is a package named libfoobar1, generates a shlibs file that
 looks something like:
  libfoobar 1 libfoobar1
 
- dh_makeshlibs -V
+=item dh_makeshlibs -V
 
-Assuming the current version of the package is 1.0-3, generates a shlibs
+Assuming the current version of the package is 1.1-3, generates a shlibs
 file that looks something like:
- libfoobar 1 libfoobar1 (>= 1.0-3)
+ libfoobar 1 libfoobar1 (>= 1.1)
 
- dh_makeshlibs -V 'libfoobar1 (>= 1.0)'
+=item dh_makeshlibs -V 'libfoobar1 (>= 1.0)'
 
 Generates a shlibs file that looks something like:
   libfoobar 1 libfoobar1 (>= 1.0)
 
+=back
+
 =cut
 
 init();