From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andreas Rottmann Newsgroups: gmane.lisp.guile.devel Subject: Re: Release time! Date: Wed, 07 Nov 2012 01:01:56 +0100 Message-ID: <87bofa5lhn.fsf@delenn.home.rotty.xx.vu> References: <87mwyvudgz.fsf@gnu.org> <87fw4ncluy.fsf@tines.lan> <87txt2tw00.fsf@gnu.org> <87obja2z54.fsf@googlemail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1352246528 13346 80.91.229.3 (7 Nov 2012 00:02:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 7 Nov 2012 00:02:08 +0000 (UTC) Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , guile-devel@gnu.org To: Ian Price Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Nov 07 01:02:17 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TVt61-0008CQ-El for guile-devel@m.gmane.org; Wed, 07 Nov 2012 01:02:17 +0100 Original-Received: from localhost ([::1]:38811 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TVt5s-0006lv-J4 for guile-devel@m.gmane.org; Tue, 06 Nov 2012 19:02:08 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:51056) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TVt5q-0006lp-25 for guile-devel@gnu.org; Tue, 06 Nov 2012 19:02:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TVt5o-0001S4-IV for guile-devel@gnu.org; Tue, 06 Nov 2012 19:02:05 -0500 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:48228) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1TVt5o-0001Rw-90 for guile-devel@gnu.org; Tue, 06 Nov 2012 19:02:04 -0500 Original-Received: (qmail invoked by alias); 07 Nov 2012 00:02:01 -0000 Original-Received: from 85-127-112-13.dynamic.xdsl-line.inode.at (EHLO cubox.home.rotty.xx.vu) [85.127.112.13] by mail.gmx.net (mp041) with SMTP; 07 Nov 2012 01:02:01 +0100 X-Authenticated: #3102804 X-Provags-ID: V01U2FsdGVkX19hwl407Kdhhkom9rGgRiwD2RmVNuyA2bXOQl90Ob ax5mPps+Kzh5+J Original-Received: from delenn.lan (delenn.home.rotty.xx.vu [IPv6:fdfb:599d:f328:2::6e]) by cubox.home.rotty.xx.vu (Postfix) with ESMTP id 418E41600B5; Wed, 7 Nov 2012 01:01:56 +0100 (CET) Original-Received: by delenn.lan (Postfix, from userid 1000) id 32467320140; Wed, 7 Nov 2012 01:01:56 +0100 (CET) In-Reply-To: <87obja2z54.fsf@googlemail.com> (Ian Price's message of "Tue, 06 Nov 2012 21:35:19 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 213.165.64.23 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:15119 Archived-At: Ian Price writes: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >>> * Figure out a way to make Guildhall modules that will be overridden by >>> a matching module in core guile (if it exists). This is important for >>> SRFIs. Ian Price's Guildhall repository contains portable >>> implementions of several SRFIs that might become part of core Guile in >>> the future, and the core versions should take priority. >> >> Could guildhall use SRFI-0 to check whether a given SRFI is already >> provided by the host=E2=80=99s Guile, and determine based on that whethe= r to >> install its own version? > > Well, maybe I could hack something that uses srfi-0, but it sounds kinda > ugly, and liable to break if a guile upgrade changed the features it expo= rted. > > Right now, a package can declare multiple 'provides' so that you can > e.g. require srfi-1 and it would pull in the appropriate package. But as > it stands, the provides are somewhat orthogonal to how the code gets > installed. > > Andreas, > Guildhall is a friendly fork of Dorodango, so what do you think about > adding this sort of thing? > I've thought about this issue some time ago, but have not yet come to a definite conclusion on how to handle this. A rough idea is to add a "proxy package" for the Scheme implementation of the destination (i.e. installation target) to the `dorodango-support' bundle, which is created upon initialization of the destination. If that proxy package would "provide" (e.g. based on a feature check) all SRFIs that are present in the target Scheme (aka "Guile" from now on), that would bring us closer to the goal. If all SRFIs required by the set of packages installed are indeed provided by Guile, no additional package would be pulled in. However, if a single package provides multiple SRFIs, of which only some are provided by Guile, that package will get installed to satisfy any requirements not met by the proxy package, and will thus *override* any core SRFI implementation in Guile that it provides as well. However, there's a reasonable (I think) workaround: no longer `provide' the SRFIs, but instead really use individual packages for them, so they can be installed on an individual basis. This is not as tedious as it might sound: the pkg-list.scm file would have to list each SRFI, but the collection of portable SRFIs can still be maintained in a single source repository and dorodango bundle (i.e. unit of distribution). Regards, Rotty --=20 Andreas Rottmann --