diff options
author | joey <joey> | 2004-11-10 23:37:23 +0000 |
---|---|---|
committer | joey <joey> | 2004-11-10 23:37:23 +0000 |
commit | 312037f7fd70f4f1527b01ff48e4178ad854a167 (patch) | |
tree | e3f33f56b1981e922d7a3f655ab901f95d3f88c9 /dh_makeshlibs | |
parent | 06b189c311c3e3033ce6bf397d0864795a98b653 (diff) | |
download | debhelper-312037f7fd70f4f1527b01ff48e4178ad854a167.tar.gz |
r1724: releasing version 4.2.244.2.24
Diffstat (limited to 'dh_makeshlibs')
-rwxr-xr-x | dh_makeshlibs | 32 |
1 files changed, 20 insertions, 12 deletions
diff --git a/dh_makeshlibs b/dh_makeshlibs index 1d57b01e..5a032790 100755 --- 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(); |