Bug 125921
| Summary: | umb-scheme has incorrect license | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Aubrey Jaffer <agj> |
| Component: | umb-scheme | Assignee: | Jindrich Novy <jnovy> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1 | CC: | agj, pknirsch, rdieter, sopwith |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-12-07 16:00:46 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Aubrey Jaffer
2004-06-14 04:34:54 UTC
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. |