Excerpts from the GCC-HOWTO regarding Library Versions
Version control
As any other program, libraries tend to have bugs which get fixed over
time. They also may introduce new features, change the effect of existing
ones, or remove old ones.
This could be a problem for programs using them; what if it was depending
on that old feature?
So, we introduce library versioning. We categorise the changes that might
be made to a library as `minor' or `major', and we rule that a `minor'
change is not allowed to break old programs that are using the library.
You can tell the version of a library by looking at its filename
(actually, this is, strictly speaking, a lie for ELF; keep reading to find
out why) : libfoo.so.1.2 has major version 1, minor version 2. The minor
version number can be more or less anything --- libc puts a `patchlevel'
in it, giving library names like libc.so.5.2.18, and it's also reasonable
to put letters, underscores, or more or less any printable ASCII in it.
COMMENT:
The ELF scheme itself provides dependencies. Debian packages should repect
that scheme and depend on libc5 and not add further restrictions by doing
something like libc5 (>=5.4.13-4) or so. It may be argued that changes of
the minor might make new compiled programs not work with prior minors due
to new functionality.
Then the dependencies should be like libc5 (>=5.4.0-0). But I think the
decision needs to be made by the maintainer.
A dependency on the patch level or delta is bad since it severely restrict
the sysadmin to run the newest libraries and not the trusted ones.
--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---
PGP Public Key = FB 9B 31 21 04 1E 3A 33 C7 62 2F C0 CD 81 CA B5
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: