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: Policies about shared libs (directly affects .deb packaging) Date: Tue, 12 Nov 2002 14:43:38 -0600 Sender: guile-devel-admin@gnu.org Message-ID: <87lm3yecxx.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 1037134855 12372 80.91.224.249 (12 Nov 2002 21:00:55 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 12 Nov 2002 21:00:55 +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 18Bi94-0003B9-00 for ; Tue, 12 Nov 2002 22:00:26 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 18Bi4w-0005ub-00; Tue, 12 Nov 2002 15:56:10 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18Bhst-0000AG-00 for guile-devel@gnu.org; Tue, 12 Nov 2002 15:43:43 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18Bhsq-00008r-00 for guile-devel@gnu.org; Tue, 12 Nov 2002 15:43:42 -0500 Original-Received: from n66644228.ipcdsl.net ([66.64.4.228] helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 18Bhsp-00008m-00 for guile-devel@gnu.org; Tue, 12 Nov 2002 15:43:39 -0500 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 2C9F162F7 for ; Tue, 12 Nov 2002 14:43:39 -0600 (CST) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 0A03321869; Tue, 12 Nov 2002 14:43:38 -0600 (CST) Original-To: guile-devel@gnu.org User-Agent: Gnus/5.090008 (Oort Gnus v0.08) 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:1688 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1688 While packaging Guile 1.6, I've tried to keep things as simple as possible. In accordance with that, and contrary to my previous discussions with people, I've been trying to see if we could get away without having to have a bunch of packages -- including one for each shared library in guile. My current Debian packaging arrangement includes four packages: Package: guile-1.6 Package: guile-1.6-libs Package: guile-1.6-dev Package: guile-1.6-doc The biggest questions surround guile-1.6-libs and guile-1.6-dev. With this arrangement, *all* the shared libs are in guile-1.6-libs, and guile-1.6-dev contains all the .a files and .so links (and the .la files for any libs that don't have their major soname in the library name i.e. libguile and libqthreads for example -- this is OK because these aren't candidates for dynamic-link). The problem is that it's OK to put all the libs in one package if *and only if* we agree to some fairly stringent restrictions upstream. If I'm thinking straight, the restrictions are: 1) We may never change the major number of any lib during a stable release cycle. Rationale: as an example, if we bumped libguile-srfi-srfi-4-v-1 to libguile-srfi-srfi-4-v-2 during the 1.6 series, and if there are applications that have been compiled against v-1, then when I release the new guile-1.6-libs package with v-2, all of those applications will be missing libraries. That's not allowed. 2) We must change the major number of *all* libs with every new guile release, i.e. when we go from 1.6 to 1.8. Rationale: imagine we didn't. Imagine we only changed libguile from libguile.so.12 to libguile.so.13 when we went from guile 1.6 to guile 1.8 but left all the other lib versions alone. Then the guile-1.8-libs package would contain libraries with file names that collided with file names from the guile-1.6-libs package (which would need to stay around to support apps that still required guile 1.6). Even if I made guile-1.8-libs conflict/replace guile-1.6-libs in this case, then you'd could have older apps that were still linked against libguile 12, but were also using the newer libguile-srfi-srfi-4 from guile-1.8 that's linked against libguile 13. Note that these two restrictions *are* fairly Draconian, and so we may not want to accept them. In that case, guile will have to be packaged for debian with one package per shared lib. However, bear in mind that this is not a panacea. We will still have upstream restrictions, they'll just be less obvious. No matter what we do, any time we change any .scm file, we have to make sure that it doesn't directly or indirectly alter the API of *any* lib inside guile in a way that requires that lib to change its major number. This includes alterations to any data structures returned or modified by any function in the API. The same goes for any change to a .c file in libguile. If that change alters anything visible to the outside world via one of our libraries, then each affected library's major number has to be changed. Of course our development behaviors coupled these two restrictions could have the practical effect of making us comply with requirements (1) and (2) anyway. If we don't want to promise to accommodate restrictions (1) and (2), then guile will have to be comprised of at least: Package: guile-1.6 Package: libguile-12 Package: libqthreads-12 Package: libguile-ltdl-1 Package: libguilereadline-v-12 Package: libguile-srfi-srfi-4-v-1 Package: libguile-srfi-srfi-13-14-v-1 Package: guile-1.6-dev Package: guile-1.6-doc During packaging I will have to be careful to split up the .scm files appropriately among the various lib packages, and we'll have to be very careful here upstream not to create inter-dependencies among the non-libguile .scm files that could cause problems across releases of different versions of a given lib. Thoughts? -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel