|
Home > Archive > Debian Developers > August 2004 > Versioning fast-development libraries (call for help with debtags packaging)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Versioning fast-development libraries (call for help with debtags packaging)
|
|
| Enrico Zini 2004-08-01, 7:47 am |
| Hello,
The debtags codebase is getting fairly stable and I'm planning to
release version 1.0. However, I have a problem wrt versioning schemes.
The whole thing is composed of:
libtagcoll
tagcoll depends on libtagcoll
tagcolledit depends on libtagcoll
libdebtags depends on libtagcoll
debtags depends on libdebtags
debtags-edit depends on libdebtags
The two libraries' interfaces are getting good, but I expect that as
other programs make use of them and the user base scales up in number,
bugs will be exposed and many small changes will be required that break
source or binary compatibility.
Of course the standard way to handle these issues would be to change
pacakage name every time source or binary compatibility changes,
however, since I don't consider the interface to be very stable yet, I
risk flooding the archive with lots of libtagcoll1.x packages and not
being able to track all of them anymore (taking care of the development
itself is already complicated enough, as you might imagine).
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.
Or better, is there someone that would like to help me out with the
packaging?
Ciao,
Enrico
--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@debian.org>
| |
| Andrew Suffield 2004-08-01, 5:50 pm |
| On Sun, Aug 01, 2004 at 01:36:10PM +0200, Enrico Zini wrote:
> Of course the standard way to handle these issues would be to change
> pacakage name every time source or binary compatibility changes,
> however, since I don't consider the interface to be very stable yet, I
> risk flooding the archive with lots of libtagcoll1.x packages and not
> being able to track all of them anymore (taking care of the development
> itself is already complicated enough, as you might imagine).
>
> 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.
No. For pre-production libraries that do not yet have stable ABIs,
there are two sane options:
a) Do not upload shared libraries (static only)
b) Do not upload any libraries
If you can't look after your ABI, don't publish one. If you publish
one, there is no way to duck all that comes with it.
We're better off with no ABI than with an unstable one.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
| |
| Enrico Zini 2004-08-01, 5:50 pm |
| On Sun, Aug 01, 2004 at 04:07:33PM +0100, Andrew Suffield wrote:
> No. For pre-production libraries that do not yet have stable ABIs,
> there are two sane options:
> a) Do not upload shared libraries (static only)
> b) Do not upload any libraries
> If you can't look after your ABI, don't publish one. If you publish
> one, there is no way to duck all that comes with it.
> We're better off with no ABI than with an unstable one.
Cool.
Now, about the "call for help with debtags packaging" part of the
subject, do you have anything to say?
Ciao,
Enrico
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Enrico Zini 2004-08-01, 8:47 pm |
| 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.
Ciao,
Enrico
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andrew Suffield 2004-08-01, 8:47 pm |
| 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:
>
>
> 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.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
| |
| Andrew Suffield 2004-08-01, 8:47 pm |
| On Sun, Aug 01, 2004 at 06:54:15PM +0200, Enrico Zini wrote:
> Now, about the "call for help with debtags packaging" part of the
> subject, do you have anything to say?
No. I don't really care about this package and have quite enough stuff
of my own that I don't have enough time to do.
[Silly question].
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
| |
| Daniel Burrows 2004-08-01, 8:47 pm |
| On Sun, Aug 01, 2004 at 08:35:44PM +0100, Andrew Suffield <asuffield@debian.org> was heard to say:
> On Sun, Aug 01, 2004 at 08:59:19PM +0200, Enrico Zini wrote:
>
> This is a very bad idea, because it destroys versioned
> dependenies. And it's in violation of policy.
In addition, it confuses users. I get periodic bug reports about
aptitude being uninstallable, when in fact the user is using the wrong
apt version for some reason.
Daniel
--
/-------------------- Daniel Burrows <dburrows@debian.org> -------------------\
| You are in a maze of twisty little signatures, all alike. |
\-Evil Overlord, Inc: planning your future today. http://www.eviloverlord.com-/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andrew Suffield 2004-08-01, 8:47 pm |
| 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:
>
> 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/ |
`. `' |
`- -><- |
| |
| Eduard Bloch 2004-08-02, 7:49 am |
| #include <hallo.h>
* Enrico Zini [Sun, Aug 01 2004, 08:59:19PM]:
> On Sun, Aug 01, 2004 at 01:36:10PM +0200, Enrico Zini wrote:
>
>
> 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.
For the records: we used this method in Mono. The upstream version is
extracted in rules using:
VERSION = $(shell dpkg-parsechangelog | grep ^Vers | cut -d\ -f2)
UPVERSION = $(shell echo $(VERSION) | sed 's,-.*,,')
and passed to substvars via
dh_gencontrol -i -- -Vmono:upversion=$(UPVERSION)
and used in debian/conrol later (Provides: libmono-${mono:upversion}).
However, a drawback of this method is that you cannot specify virtual
packages as build-depends so we use this method only where it is
absolutely necessary.
Regards,
Eduard.
--
Viele Politiker, die in der Opposition geschmeidige Düsenjäger waren,
werden an der Macht bedächtige Segelflieger.
-- Ignazio Silone
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Joel Baker 2004-08-02, 5:58 pm |
| On Mon, Aug 02, 2004 at 03:02:05AM +0100, Andrew Suffield wrote:
> On Sun, Aug 01, 2004 at 02:03:06PM -0600, Joel Baker wrote:
>
> 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].
That would be why I said it wasn't the right solution for the library issue;
mostly I was just noting it existed (and in fact, for kernels, is often going
to look something like:
Provides: kernel-abi-1-0, kernel-abi-1-1, kernel-abi-2-0
Since it is exceedingly common for BSD-land kernels to provide emulation
abilities for older ABIs (in fact, it's more or less required, so that
you can boot under the new kernel long enough to do 'make installworld'
on the rest of the core system, which has to talk to both old and new
core-userland stuff like 'ps', which is their way of upgrading).
Anyway. I think we're in (not so) violent agreement here. Anything which
thinks it needs this should have a clear and obvious reason that it makes
sense (though I still wish we had versioned virtual dependancies, but
that's huge bucket of nastyness that *still* wouldn't necessarily resolve
situations like the above...)
--
Joel Baker <fenton@debian.org> ,''`.
Debian GNU/kNetBSD(i386) porter : :' :
`. `'
http://nienna.lightbearer.com/ `-
| |
| Chris Cheney 2004-08-02, 5:58 pm |
| 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:
>
>
> 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.
Unless I am misunderstanding what you mean this shouldn't be needed if
you use libtool and its versioning system. Look into how its current,
revision, age system works.
Chris
|
|
|
|
|