Red Hat Bugzilla – Bug 169731
Review Request: ecl - Embeddable Common-Lisp
Last modified: 2007-11-30 17:11:14 EST
ECL (Embeddable Common-Lisp) is an interpreter of the Common-Lisp
language as described in the X3J13 Ansi specification, featuring CLOS
(Common-Lisp Object System), conditions, loops, etc, plus a translator
to C, which can produce standalone executables.
Missing BuildRequires: m4 texinfo
Created attachment 121806 [details]
Could use a -devel package
I am not sure it makes much sense to split off a devel package.
Ecl can be considered a development package in itself (we took
this view for clisp for example).
IF a devel is split off, then we must decide what belongs to it
(apart from the .h files).
(In reply to comment #3)
> I am not sure it makes much sense to split off a devel package.
> Ecl can be considered a development package in itself (we took
> this view for clisp for example).
> IF a devel is split off, then we must decide what belongs to it
> (apart from the .h files).
I notice a clisp-devel package, for what it's worth.
install.html is not needed, do not include.
also, xorg-x11-devel BuildRequires is unneeded.
Missing m4 and texinfo as per comment 1.
Let's get this to build first.
(In reply to comment #4)
> I notice a clisp-devel package, for what it's worth.
Oh, I meant gcl.
What you propose that should go into the devel package?
(In reply to comment #5)
> What you propose that should go into the devel package?
Any headers or other devel files that would be used to build something against
the program, but not to use it. If you required certain headers to use the ecl
compiler then they don't need to be, for example gcc includes some devel files.
I don't use this so I do not know what the typical use case requires.
As far as I could find out, compiling with ecl
(which arguably is one of the main uses of the
package) requires the files in /usr/lib/ecl
(including the .h files). Thus, I prefer not to
split the package.
(In reply to comment #7)
> As far as I could find out, compiling with ecl
> (which arguably is one of the main uses of the
> package) requires the files in /usr/lib/ecl
> (including the .h files). Thus, I prefer not to
> split the package.
Fine with me.
For FC5 you'll have to change to modular X BuildRequires if you need X stuff.
I made some small adjustements:
I left the old BuildRequires for X for now, since I test on FC4.
As soon as the package is imported into cvs, it will be tested with
new BuildRequires for devel.
You will likely want to make a note of the lack of a devel package in the spec.
* perl is not needed as a BuildRequires
- rpmlint checks return:
* some devel-file-in-non-devel-package, ignoring
* dangling symlinks from the debuginfo package back to the build dir, harmless
W: ecl-debuginfo objdump-failed, not serious
- package meets naming guidelines
- package meets packaging guidelines, exception for no devel package
- license (LGPL) OK, text in %doc, matches source
- spec file legible, in am. english
- source matches upstream
- package compiles on FC4 i386
- no missing BR
- no locales
- not relocatable
- owns all directories that it creates
- no duplicate files
- permissions ok
- %clean ok
- macro use consistent
- code, not content
- no need for -docs
- nothing in %doc affects runtime
- no need for .desktop file