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 (= [EMAIL PROTECTED]@), e2p2g (= [EMAIL PROTECTED]@), uuid1g (= [EMAIL PROTECTED]@) === 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 <[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/>
