Re: libgal sonames
On Sat, 2001-09-01 at 12:30, Guus Sliepen wrote:
> On Sat, Sep 01, 2001 at 10:48:45AM +0100, Edward Betts wrote:
>
> > Norbert Veber <nveber@debian.org> wrote:
> > > Every time you change the soname, and the new version is installed in the
> > > debian archive, the old one is removed. At that point 22 (at the latest
> > > count) different debian packages need to be recompiled. Some of them are
> > > quite large.
> >
> > Why is the old one removed? If we kept the libgal packages until nothing
> > depended on it, and then removed it we would not have a problem. I suppose it
> > is something to do with libgal-data.
>
> Because the packages are built from one source (gal), and it's a bit hard to
> keep two versions of the same source! But whether or not Debian should/could
> keep different versions of libgal, Norbert still has a valid point: sonames
> shouldn't change that often. Last week I packaged gnuvd-gnome, and at that time
> libgal9 was the most recent version. Yesterday Norbert filed a bug to inform me
> of the demise of libgal9 and rise of libgal11. I mean, come on, 2 new *MAJOR*
> versions of the same library in only ONE week?! What would you say if next week
> glibc 4 was packaged?
>
gal is a library in development, and this is stated in several places.
That's the reason there are so many major versions. At every change,
there are binary incompatibilities, and that's what sonames are used
for. If you just increase the minor versions, you break the system,
since packages will think that that version is ok, although there are
binary incompatibilities.
The problem is not in gal, but in stable applications depending on it.
In fact, libgal is only intended to be used by gnumeric and evolution.
Even more, libgal is just developed for evolution, so if tomorrow
evolution needs a binary-incompatible change in libgal, it will be done,
no matter what applications would be broken because of this, so expect
to see this pace of major versions for a long time. As I said, libgal is
not a "normal" library in the sense that it's got a published API that
applications can rely on; it is just a shared code repository for
evolution and gnumeric.
So what I'd do myself is to not link stable applications with gal, and
if this is impossible (application depending on gal), go tell those app
maintainers to provide a gal-free version.
That's what I did myself in gnome-db: I was using gal and getting
hundreds of bug reports every week for binary incompatibilities. So, I
just use GTK and gnome-libs now.
cheers
--
Rodrigo Moya <rodrigo@gnome-db.org> - <rodrigo@ximian.com>
http://www.gnome-db.org/ - http://www.ximian.com/
Reply to: