From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.lisp.guile.devel Subject: Re: Release now? Date: Thu, 27 Feb 2003 14:02:05 -0600 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <873cm9lcg2.fsf@raven.i.defaultvalue.org> References: <87of50tdcz.fsf@raven.i.defaultvalue.org> <873cmbpyij.fsf@raven.i.defaultvalue.org> <873cm9oe9k.fsf@raven.i.defaultvalue.org> <87r89tlf07.fsf@raven.i.defaultvalue.org> <87isv5leom.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1046376457 3786 80.91.224.249 (27 Feb 2003 20:07:37 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 27 Feb 2003 20:07:37 +0000 (UTC) Cc: guile-devel@gnu.org Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18oUJM-0000yI-00 for ; Thu, 27 Feb 2003 21:07:21 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18oUFy-0003A9-08 for guile-devel@m.gmane.org; Thu, 27 Feb 2003 15:03:50 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18oUFV-0002mU-00 for guile-devel@gnu.org; Thu, 27 Feb 2003 15:03:21 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18oUFI-0002Ye-00 for guile-devel@gnu.org; Thu, 27 Feb 2003 15:03:09 -0500 Original-Received: from dsl093-098-016.wdc1.dsl.speakeasy.net ([66.93.98.16] helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18oUEH-0001bB-00 for guile-devel@gnu.org; Thu, 27 Feb 2003 15:02:05 -0500 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 433A03791; Thu, 27 Feb 2003 14:02:05 -0600 (CST) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 2D6CDD4E9B; Thu, 27 Feb 2003 14:02:05 -0600 (CST) Original-To: Greg Troxel In-Reply-To: (Greg Troxel's message of "27 Feb 2003 14:36:54 -0500") User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:2004 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2004 Greg Troxel 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