Christian Schwarz writes:
>
> [Sorry for the late reply.]
>
> On Fri, 16 Jan 1998, Yann Dirson wrote:
>
> > Hi there,
> >
> > Some upstream packages (eg. e2fsprogs) contain shared libraries which
> > can be debian-packaged in their own package (eg. libcom_err, now in
> > packages comerr{2g,g-dev}).
> >
> > Until now, I let the versions of library packages be the same as the
> > e2fsprogs deb-package's version. However, this means that the
> > package-version for a shared library does not match the library
> > version.
> >
> > Though it is not critical, it may be good IMHO to provide both version
> > numbers (the one of the lib itself, and the one of the source-package
> > providing it) to be the upstream-version-number of the package.
> > The library version will show the library's minor version-number,
> > which does not appear anywhere else in control info, while the
> > source-package's version will ensure the upstream version will bounce
> > in the case where the library code changes and the upstream maintainer
> > forgets to increment the lib's version.
>
> What would the advantages of such a policy be?
>
> If the different major revisions of the shared library are not compatible
> (usually the case, since important changes are the reason for incrementing
> the major revision) then the package will probably contain the major
> revision number in the package name already, as in "libreadlineg2_2.1-7",
> for example.
Yes, but that's not what I meant. The issue is about the lib's
minor/pl rev. numbers (in the case of what I call a non-standalone
lib[1], which is not the case of readline), which don't get their way
anywhere in the case where only the source-package revision is used.
And when only the lib's rev. is used, then there is a problem to chose
a deb-revision: we can't take the deb-revision of the main package,
because the main package may come in a new upstream release, thus
resetting the deb-revision, without the lib-revision being
modified. Then the lib's deb-revision would need to be handled
separately, ie. manually, which is IMHO not a good way of doing it.
Maybe it would be possible (in theory, but the current tools don't
seem to allow it in a simple manner) to issue releases of a lib only
when the lib's package would require it (ie. not each time the
source-package gets deb-modified), but there will be problems for that
to ensure, between 2 upstream releases, that the lib has not been
patched without its version-number getting increased.
The solution of using both the lib's version and the main package's
revision-number in the lib-package's revision-number would be
sub-optimal in this respect (but that would be no worse as it is now),
but would add the full lib-revision-number.
[1] I mean by non-standalone lib a lib that is provided by a source
package, with its revision-number being independant of the source
package's revision-number. The best example I have is e2fsprogs_1.10
provising release 2.0 of libcom_err.
PS. sorry if I'm not clear enough, but I've got problems to
concentrate these days... (crying baby, etc.)
I still hope this mail will be represent more accurately than my
original post what I want to express.
Regards,
--
Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer,
alt-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux:
debian-email: <[EMAIL PROTECTED]> | more powerful, more stable !
http://www.a2points.com/homepage/3475232 | Check <http://www.debian.org/>
