unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Rob Browning <rlb@defaultvalue.org>
Cc: guile-devel@gnu.org
Subject: Re: Release now?
Date: Thu, 27 Feb 2003 14:02:05 -0600	[thread overview]
Message-ID: <873cm9lcg2.fsf@raven.i.defaultvalue.org> (raw)
In-Reply-To: <rmiznohzfah.fsf@fnord.ir.bbn.com> (Greg Troxel's message of "27 Feb 2003 14:36:54 -0500")

Greg Troxel <gdt@ir.bbn.com> 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


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


  reply	other threads:[~2003-02-27 20:02 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-24 12:37 Release now? Mikael Djurfeldt
2003-02-24 13:08 ` Dale P. Smith
2003-02-24 13:21   ` Mikael Djurfeldt
2003-02-24 13:32 ` Greg Troxel
2003-02-25 13:34   ` Marius Vollmer
2003-02-25 16:08     ` Greg Troxel
2003-02-25 18:38       ` Rob Browning
2003-02-26  1:51         ` Greg Troxel
2003-02-26  2:27           ` Rob Browning
2003-02-27 14:25             ` Greg Troxel
2003-02-27 15:21               ` pkg-config support for guile Greg Troxel
2003-03-22 23:31                 ` Marius Vollmer
2003-04-23 21:22                   ` Greg Troxel
2003-05-16 23:21                     ` Marius Vollmer
2003-02-27 16:54               ` Release now? Rob Browning
2003-02-27 18:07                 ` Greg Troxel
2003-02-27 18:45                   ` Rob Browning
2003-02-27 19:25                     ` Greg Troxel
2003-02-27 20:14                       ` Rob Browning
2003-02-27 19:06                 ` Rob Browning
2003-02-27 19:13                   ` Rob Browning
2003-02-27 19:36                     ` Greg Troxel
2003-02-27 20:02                       ` Rob Browning [this message]
2003-02-27 20:54                         ` Greg Troxel
2003-02-27 21:07                           ` Dale P. Smith
2003-02-27 21:30                             ` Dale P. Smith
2003-02-27 21:47                           ` Rob Browning
2003-04-25 19:26                           ` Neil Jerram
2003-02-25 16:28     ` Andreas Rottmann
2003-02-24 18:35 ` Rob Browning
2003-02-25 13:20 ` Marius Vollmer
2003-03-03 14:06   ` Mikael Djurfeldt
2003-04-25 19:28   ` Neil Jerram
2003-04-25 22:59     ` Marius Vollmer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=873cm9lcg2.fsf@raven.i.defaultvalue.org \
    --to=rlb@defaultvalue.org \
    --cc=guile-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).