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: packaging the add-on libs... Date: Thu, 10 Oct 2002 00:03:42 -0500 Sender: guile-devel-admin@gnu.org Message-ID: <87vg4aevgx.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1034226334 2898 127.0.0.1 (10 Oct 2002 05:05:34 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 10 Oct 2002 05:05:34 +0000 (UTC) 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 17zVVj-0000kG-00 for ; Thu, 10 Oct 2002 07:05:23 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17zVUW-0002Vw-00; Thu, 10 Oct 2002 01:04:08 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17zVUM-000282-00 for guile-devel@gnu.org; Thu, 10 Oct 2002 01:03:58 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17zVUA-0001Up-00 for guile-devel@gnu.org; Thu, 10 Oct 2002 01:03:52 -0400 Original-Received: from n66644228.ipcdsl.net ([66.64.4.228] helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17zVU9-0001Jv-00 for guile-devel@gnu.org; Thu, 10 Oct 2002 01:03:45 -0400 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 74D081CAB for ; Thu, 10 Oct 2002 00:03:42 -0500 (CDT) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 3E1321F15; Thu, 10 Oct 2002 00:03:42 -0500 (CDT) Original-To: guile-devel@gnu.org Original-Lines: 50 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-pc-linux-gnu) Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:1504 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1504 I spoke with Marius a little while back about some of the complexities involved in properly managing the versioning of our add-on libs, both those we provide, and those provided by others, and working on packaging guile 1.6 makes some of these issues clearer and more immediate. Consider libguile-srfi-srfi-4-v-1 which will be linked against a particular libguile. What guarantees are we going to make about future releases of this add-on lib? Do we guarantee that we'll always change its major number whenever we release a new libguile? It seems like we must, since otherwise we could have outside apps or libs linked against a set of add-on libs that point to a mixed set of libguile versions. As an example, say libguile13 ships with libguile-foo-v-1 and libguile-bar-v-7, and libguile14 ships with libguile-foo-v-2 and libguile-bar-v-7. At this point we have a problem. Any older app on the system that was originally linked against libguile13, libguile-foo-v-1, and libguile-bar-v-7 would still have all its package depdendencies satisfied and would link at runtime without any problems (at least I think it would), but it would be using libguile13 via foo and libguile14 via bar. Presuming my analysis is right, I guess maybe we can just try to make sure the rules about versioning your add-on libraries are clear, but I'm concerned that a lot of people (especially people writing add-on libs outside the core -- if we end up with a lot of them) may not always remember or know the rules, and it seems like the resulting bugs could be subtle and hard to track down. One clear solution might be to just establish the convention that you always embed the libguile major version number in the add-on lib's name. This seems like it would eliminate the possibility for error on this front, but is a little unusual. i.e. instead of libguile-srfi-srfi-4-v-1, etc., you'd have: libguile12-srfi-srfi-4-v-1 libguile12-srfi-srfi-13-14-v-3 libguile12-foo-bar-v-4 etc. Thoughts? -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel