Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 45826

Summary: dev-libs/slib incorrectly depends on guile
Product: Gentoo Linux Reporter: Bardur Arantsson <bugs-gentoo.org>
Component: Current packagesAssignee: Scheme Project <scheme>
Status: RESOLVED REMIND    
Severity: normal CC: bradmwalker, plh, seemant
Priority: High    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: slib-3.1.1.ebuild (proposal1)
dev-scheme/slib/slib-3.1.4.ebuild
dev-scheme/slib/slib-3.1.4.ebuild
dev-scheme/slib/slib-3.1.4.ebuild

Description Bardur Arantsson 2004-03-26 11:34:32 UTC
The current ebuilds for dev-libs/slib seem to assume that the only valid Scheme interpreter is Guile; at least two other Scheme interpreters are currently in Portage: mit-scheme and mzscheme (both of which are supported by slib).

I'm also currently writing an ebuild for SISC (http://sisc.sf.net) which also supports slib. (Not submitted for inclusion in Portage yet because of this issue).

To solve the problem, I propose the following:

1) A virtual "dev-lisp/scheme" package is added. It can be provided by guile, mit-scheme, mzscheme and any other Scheme implementation. (Defaulting to guile, but since these implementations are quite different, I would imagine that most other packages would still depend on a particular Scheme implementation).

2) slib is changed to depend on this virtual "dev-lisp/scheme" package instead of depending specifically on guile. Since packages which currently depend on slib presumably also depend explicitly on guile, this should not cause any problems with existing ebuilds.

3) the install location of slib is changed to the more generic /usr/share/slib. If necessary, symlinks can be created from the "site" directory of each of the Scheme implementations to this directory (upon installing slib).

4) the current postinstall procedure is changed to include module registration for the other Schemes which support slib. I have no interest in adding support for mit-scheme or mzscheme, but will add the code required for SISC. The current registration procedure for Guile does not have be changed, it just needs to check that guile is actually installed before attempting the registration.

An alternative approach to point 4 is to just create slib-guile, slib-sisc, etc. ebuilds which do the necessary work for each individual Scheme implementation (and install into their specific directories), but I think it would be much better for maintainability if the "unified ebuild" approach were taken.

I think all of the above modifications are necessary for being able to properly supporting slib in any non-guile Scheme implementation. I would be quite happy to do the necessary changes to the slib ebuilds, if the maintainers think that this is a sensible course of action.

Reproducible: Always
Steps to Reproduce:
Comment 1 Jason Wever (RETIRED) gentoo-dev 2004-04-03 08:52:58 UTC
Sorry for taking so long to get back to you.

I'm the defacto maintainer for slib, but don't really know much about it.

Points 1,2 and 3 should be pretty straight-forward

Point 4 I agree with you about keeping the unified ebuild.

I'll look into doing this soon.  If you have done any work locally towards this, feel free to attach.
Comment 2 Bardur Arantsson 2004-04-05 02:36:50 UTC
Created attachment 28726 [details]
slib-3.1.1.ebuild (proposal1)

This ebuild demonstrates the general idea:

0) Depends changed from >=guile-1.4 to virtual/scheme. (Of course, the virtual
must be added and PROVIDE=virtual/scheme must be added to the Guile ebuild for
the dependencies to work properly).

1) Installs into /usr/share/slib.

2) If guile is installed, installs symlink from /usr/share/guile/site/slib to
/usr/share/slib, so that everything works as before.

3) I've added a commented-out section showing how SISC would be handled.
(Haven't finished the ebuild for that yet, so this is just an example).

I've tested that the package registration thingy does the right thing on my
system, but I haven't actually tried *using* slib from Guile.
Comment 3 Jason Wever (RETIRED) gentoo-dev 2004-05-29 17:15:05 UTC
Just an update to let you know I am still working on this, but at a rather slow pace unfortunately.  Hoping to have something this week though.
Comment 4 PL Hayes 2005-08-16 23:45:37 UTC
How is this coming along? I've just installed mit-scheme and may install others
(I already have guile). I'd suggest /usr/share/scheme/slib instead of
/usr/share/slib because there may be many more scheme libraries in future. Also,
shouldn't this package be in dev-scheme rather than dev-libs?

On a related note I see scheme implementations spread out over dev-lisp,
dev-util, dev-lang and dev-scheme. This is very inconvenient and confusing. 
Comment 5 Alec Warner (RETIRED) archtester gentoo-dev Security 2006-09-25 14:39:54 UTC
antarus@kyoto ~/code/pkgcore/bin $ time ./pquery --revdep=dev-libs/slib -v
 * app-office/gnucash-1.8.11
     description: A personal finance manager
     homepage: http://www.gnucash.org/

 * app-office/gnucash-2.0.1
     description: A personal finance manager.
     homepage: http://www.gnucash.org/

 * dev-libs/g-wrap-1.3.4-r1
     description: A tool for exporting C libraries into Scheme
     homepage: http://www.gnucash.org
Comment 6 Jakub Moc (RETIRED) gentoo-dev 2006-10-31 05:02:07 UTC
(In reply to comment #5)

A better one :)

# pquery --raw --revdep dev-libs/slib
app-office/gnucash-1.8.11
app-office/gnucash-1.8.12
app-office/gnucash-2.0.1
app-office/gnucash-2.0.2
dev-libs/g-wrap-1.3.4-r1
Comment 7 Seemant Kulleen (RETIRED) gentoo-dev 2006-12-18 08:40:35 UTC
Matt, your input on this would be greatly appreciated!
Comment 8 Marijn Schouten (RETIRED) gentoo-dev 2006-12-19 07:46:56 UTC
Actually I think slib shouldn't depend on any scheme implementation, including a virtual. Instead I think that each Scheme implementation that supports slib should have a use flag to enable support for it and which would turn on slib as a dependency and install slib for that implementation. (Slib has some documentation for how to do that.)

Of course it is also possible to have slib use-flag depend on all available scheme implementations and do the installation, but I don't think that is the right way. All slib stuff would be in one place, but the ebuilds for every Scheme implementation with support for slib would be in two places. Every time you'd install a new implementation you would have to remerge slib too.

A virtual/scheme might be useful if say gnucash would support multiple scheme implementations and another package too and both sets would be exactly the same. Otherwise we'd need virtual/gnucash-scheme and virtual/<other>-scheme which would defeat the purpose of having a virtual. Maybe r6rs will get us there.
Comment 9 Marijn Schouten (RETIRED) gentoo-dev 2006-12-20 11:17:42 UTC
Created attachment 104455 [details]
dev-scheme/slib/slib-3.1.4.ebuild

New ebuild for 3a4 with versioning magic by masterdriverz.

doesn't depend on anything except unzip and doesn't install itself for any implementation. I think as it should be.
Comment 10 Marijn Schouten (RETIRED) gentoo-dev 2006-12-21 02:56:12 UTC
Created attachment 104500 [details]
dev-scheme/slib/slib-3.1.4.ebuild

with working version magic this time
Comment 11 Marijn Schouten (RETIRED) gentoo-dev 2006-12-21 10:45:28 UTC
There seems to be a problem with guile-1.8.1 and slib-3a4: http://www.mail-archive.com/bug-guile%40gnu.org/msg03930.html
I'm also getting:
ERROR: Unbound variable: slib:features
but not the ABORT stuff. I tried the suggested patch, but it doesn't seem to help.
Comment 12 Marijn Schouten (RETIRED) gentoo-dev 2006-12-22 08:08:32 UTC
Created attachment 104580 [details]
dev-scheme/slib/slib-3.1.4.ebuild

better new install location, improved version magic without external executable (tr), works with guile-1.6.8 ebuild.

This version depends on the scheme implementation to do the installation, so it will not work with older versions of guile-ebuild than 1.6.8.
Comment 13 Marijn Schouten (RETIRED) gentoo-dev 2006-12-24 06:07:29 UTC
Actually I now, after some experience, think it is stupid to let scheme implementations have an slib use flag. It doesn't affect compilation of the scheme implementation at all, but if it is changed recompilation is what will result. Unnecessary recompilation is very annoying.

I think the same problem will result once more implementations get gentoo support for slib. Some may want to compile slib. The best solution I can now think of is to create new ebuilds for installing slib for a particular scheme implementation, such as "slib-for-guile", "slib-for-mzscheme" etc.
Comment 14 brad walker 2006-12-30 13:52:54 UTC
(In reply to comment #11)
> There seems to be a problem with guile-1.8.1 and slib-3a4:
> http://www.mail-archive.com/bug-guile%40gnu.org/msg03930.html
> I'm also getting:
> ERROR: Unbound variable: slib:features
> but not the ABORT stuff. I tried the suggested patch, but it doesn't seem to
> help.

(In reply to bug #125468, comment #26)
> From http://www.gnu.org/software/guile-gnome/
> "Also note that we have bumped our dependency on G-Wrap to an as-yet-unreleased
> version, and removed the dependency on SLIB."
> 
> So can you really use slib functions from guile-1.8.*?

squirrel guile # guile
guile> (version)
"1.8.1"
guile> (use-modules (ice-9 slib)) ;; before ice-9/slib.scm workaround
ERROR: Unbound variable: slib:features
ABORT: (unbound-variable)
guile> (use-modules (ice-9 slib)) ;; after ice-9/slib.scm workaround
WARNING: (guile-user): imported module (ice-9 slib) overrides core binding `provided?'
WARNING: (guile-user): imported module (ice-9 slib) overrides core binding `provide'
guile> (require 'new-catalog) ;; create catalog
guile> (real-exp 1) ;; new in slib 3.1.4 but not loaded

Backtrace:
In standard input:
   3: 0* (real-exp 1)

standard input:3:1: In expression (real-exp 1):
standard input:3:1: Unbound variable: real-exp
ABORT: (unbound-variable)
guile> (require 'srfi-94) ;; load real-exp, real-ln
guile> (real-exp 1)
2.71828182845905
guile> (real-ln (real-exp 1))
1.0
guile> 
Comment 15 Marijn Schouten (RETIRED) gentoo-dev 2007-01-12 18:31:51 UTC
I'm leaning towards introducing an ebuild guile-slib, but I want to get slib working with a Scheme compiler first, before deciding on a fix. mit-scheme, gambit or maybe SISC, chicken or PLT/Dr/MzScheme.