On Sun, Aug 01, 2004 at 02:03:06PM -0600, Joel Baker wrote: > On Sun, Aug 01, 2004 at 08:35:44PM +0100, Andrew Suffield wrote: > > On Sun, Aug 01, 2004 at 08:59:19PM +0200, Enrico Zini wrote: > > > On Sun, Aug 01, 2004 at 01:36:10PM +0200, Enrico Zini wrote: > > > > > > > Is there some more restrictive versioning and dependancy scheme I could > > > > use? I tried setting shlibs so that packages would depend on =version > > > > instead of >=version, but that seems to be a bit too restrictive. > > > > > > Nice folks in IRC suggested me to Provide: libtagcoll-api-1.0 and > > > Depend: libtagcoll-api-1.0, then change the virtual package depend when > > > the API/ABI changes. > > > > > > It's a solution that I like very much and I want to post it here for the > > > records. > > > > This is a very bad idea, because it destroys versioned > > dependenies. And it's in violation of policy. > > Not that it's the right solution for this, but it happens to be the ONLY > solution when you need to version a virtual dependancy (IE, multiple > packages can legitimately provide implementations of a specific API, and > the things that use that API don't care which one does, as long as something > is there). That would indicate a much more strongly defined ABI than the one of a regular shared library - like the perl ABI. These things are maintained upstream in a rigorous manner, in both forwards *and* backwards directions, in order to make ABI compatibility work at all. Very different beast, and the properties I just outlined are the reasons why it works there, and not here. [Note that such a thing is still distinct from the library ABI, even if it happens to be implemented in a library, and should be versioned in a completely independent manner]. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- |
Attachment:
signature.asc
Description: Digital signature