Description of problem: Guile as distributed in the Fedora (and previous RedHat) distributions requires the umb-scheme RPM for its SLIB directory. SLIB is a GNU package; but it is not released under the GNU GPL. The Fedora umb-scheme RPM incorrectly declares its license to be the GNU GPL. Using umb-scheme for this purpose creates RPMs for multiple platforms while the only portion used, SLIB, is actually noarch. It also denies visibility to SLIB and recognition for its authors. Please stop pirating SLIB through umb-scheme and instead use the SLIB RPMs which I distribute from http://swiss.csail.mit.edu/~jaffer/SLIB Version-Release number of selected component (if applicable): all How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Hi Aubrey, I really don't understand why the slib package is distributed along with umb-scheme as I was recently reassigned to resolve this bug. I think it deserves its own rpm. The problem is probably with dependencies which have to be figured out when slib is removed from the umb-scheme rpm. It solves also the problem with the different license. If you agree I can propose adding separate package for slib and removing slib from umb-scheme. greetings, Jindrich
I agree that separating SLIB from UMB-Scheme is the right thing to do. Among core RPMs, I think you will find that Guile is the only package requiring SLIB. http://swiss.csail.mit.edu/ftpdir/scm/slib-3a1-1.noarch.rpm is the current SLIB distribution. Thanks!
I have discussed slib removal from umb-scheme and a final conclusion is to remove slib from umb-scheme and adding it to the guile rpm (with proper recognition of slib license and authors). Now we're waiting for guile package maintainer opinion because he's now on vacation. Jindrich
Incorporating SLIB into Guile will again have its 3.MB of noarch code replicated for each Guile platform. Although Guile may currently be the only *core* package using SLIB, there are other packages which use it: JACAL, Schelog, G-wrap, GNU-cash, Meroon, SCM, umb-scheme, mzscheme (Dr. Scheme), scheme48, ... I believe that Guile and these applications will best be served if SLIB is a distinct noarch RPM.
Ok, we'll reconsider this and keep you informed about the planned chnages to umb-scheme and slib.
Having the same slib code included in binary packages for different architectures isn't a big issue in this case. We have the disk space to spare here, and it shouldn't impact the user at all since they'll only wind up with one copy. Historically, the other packages that use slib haven't been relevant to the majority of our users, so splitting slib out for them is not a priority. GNUCash is not an issue since gnucash uses guile anyways. Overall, the benefits of not having Yet Another Package for users to worry about outweigh the benefits of having slib packaged separately. Unless something major changes with FC users needs, or we've forgotten to cover some major benefits, then I think inclusion in the guile package is the path to take.
It wouldn't be "yet another package" because it replaces umb-scheme. Moving SLIB from total obscurity buried inside UMB-Scheme to total obscurity buried inside Guile is not the change I was hoping for. It would continue to deny visibility to SLIB and recognition for its authors.
Aubrey, I have good news for you, we decided to replace umb-scheme with slib, so that slib will have its own package. Unfortunately it will not be done in FC3t2 because a devel freeze is today and it would be pretty hard to resolve dependencies in such a haste. The change will appear in the next release. Jindrich
Thanks!
I just included the new slib package into CVS and built it. The new package is slib-3a1-1.noarch.rpm.