guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Release now?


From: Rob Browning
Subject: Re: Release now?
Date: Thu, 27 Feb 2003 14:02:05 -0600
User-agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu)

Greg Troxel <address@hidden> writes:

>   Putting the guile version in the lib name would fix that too, but I
>   think there's still a reasonably strong sentiment against
>   libguile-12-gwrap-glib-2-gl-3-whatever-4.
>
> But is the sentiment well founded?  We've gone down the path of lib
> symlinks, and it seems that it really is pretty hairy.
>
> I hold up glib 1.2/2 as an example of a low-pain solution to what
> would otherwise have been a very painful and chaotic transition.

How do they handle it, and do they have the same dynamic-link issues?
Also, how do they handle the app1 -> libfoo -> libgtk, and app1 ->
libbar -> libbgtk with respect to upgrading, during the the period
when libfoo has been recompiled against the new libgtk, but libbar on
the system hasn't -- do they just require all libraries in the chain
to mention the versions of all the other libs they're linked against?

> And I would suggest not keying on major numbers, but on compile time
> changes, and thus the release numbers.

Well it's actually the major numbers that are required to indicate
binary compatibility, so they're the most "correct" indicator in
general.  However in guile, we've committed to changing all the lib
major numbers with each major release, so they're effectively
equivalent.

> Or does debian insist on upgrading a package without upgrading
> things that depend on it?

Right now Debian actually packages all the guile libs in
guile-1.6-libs, but that's only possible because we're planning to
bump the major sonames with every major release.  If we didn't then
binary packaging systems would have to have one binary package per
lib, i.e. libguile12*.deb, libguile-srfi*.deb, to accomodate for the
possibility that we might change the soname for some libs, but not all
of them in a given major release (i.e. unless we bump all of them,
guile-1.8-libs would have files that conflicted with guile-1.6-libs).

> If so, I think one has to have a new package name that can coexist
> on every incompatible change.  (NetBSD's make update does a
> pkg_delete -r and then rebuilds all the depending packages.)

One thing to keep in mind is that with a source-based distribution
like bsd or gentoo, many of these problems go away.  Having to support
multiple versions of installed binary packages definitely complicates
things.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4




reply via email to

[Prev in Thread] Current Thread [Next in Thread]