Re: Versionning of non-standalone library packages
Christian Schwarz writes:
> On Thu, 22 Jan 1998, Yann Dirson wrote:
>
> [snip]
> > 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.
> [snip]
> > [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.
>
> Ok, now I got your point. But I'm still not convinced that your solution
> (including the shlib's version number in the package name) is good. Just
> image a package which contains several shared libraries with different
> version numbers.
Yes, my suggestion does not address that case (which I do have to
handle with e2fslibs ;). Note however that this suggestion was to
include the shlib's version numbers in the package's *version*, not in
its name - only the soname gets there, as usual.
This situation, of eg. e2fslibsg containing libext2fs, libe2p and
libuuid could be addressed the same way, if only we had versioned
Provides: fields:
===
Package: e2fslibsg
Provides: ext2fs2g (= 2.3-@VERSION@), e2p2g (= 2.3-@VERSION@), uuid1g (= 1.1-@VERSION@)
===
With @VERSION@ (or whatever syntax), being expanded by dpkg_gencontrol
to the main package's version (eg. 1.10-11), which e2fslibsg will be
granted.
Maybe there would be semantic problems to be solved with versioned
provides involving relational ops like < and >, but the = op would be
quite straightforward to implement, as it seems to me [don't rely too
much on this opinion, I didn't look into dpkg's code for this].
BTW, is it because of these possible semantic problems that we don't
have versioned provides ?
> If the point is just to get the information about which shlibs are
> included out of the package itself, I suggest to mention the shlibs in the
> Description or some other control field.
But then, no deps could be set against a specific release of the
shared lib (eg. because of known bugs).
--
Yann Dirson <ydirson@a2points.com> | Stop making M$-Bill richer & richer,
alt-email: <dirson@univ-mlv.fr> | support Debian GNU/Linux:
debian-email: <dirson@debian.org> | more powerful, more stable !
http://www.a2points.com/homepage/3475232 | Check <http://www.debian.org/>
Reply to: