Bug 431250 (librep)

Summary: Review Request: librep - An embeddable LISP environment
Product: [Fedora] Fedora Reporter: ritz <rkhadgar>
Component: Package ReviewAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: fedora-package-review, itamar, jonathan.underwood, michal, notting, tibbs
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: 2009-03-09 20:07:36 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 201449, 496433, 431249, 431251    
Attachments:
Description Flags
modified librep spec file none

Description ritz 2008-02-01 14:15:08 EST
Spec URL: http://people.redhat.com/rkhadgar/personal/fedora/librep.spec
SRPM URL: http://people.redhat.com/rkhadgar/personal/fedora/librep-0.17-2.svn20071102.fc8.src.rpm
Description: 
This is a lightweight Lisp environment for UNIX. It contains a Lisp
interpreter, byte-code compiler and virtual machine. Applications may
use the Lisp interpreter as an extension language, or it may be used
for standalone scripts.
Comment 1 Jason Tibbitts 2008-02-02 10:24:20 EST
This fails to build for me:

/bin/sh ../libtool --mode=link gcc  -o repdoc repdoc.o -lgdbm
/bin/sh: ../libtool: No such file or directory
make[1]: *** [repdoc] Error 127
make[1]: Leaving directory `/builddir/build/BUILD/librep-0.17/src'
make: *** [src/repdoc] Error 2

Adding BuildRequires: libtool gets things to progress further, until:

Checking for unpackaged file(s): /usr/lib/rpm/check-files
/var/tmp/librep-0.17-2.svn20071102.fc9-root-mockbuild
error: Installed (but unpackaged) file(s) found:
   /usr/share/info/dir

You need to explicitly delete this file, which is generated as part of the
texinfo compilation but should never be part of any package.  At the end of
%install:
  rm -f $RPM_BUILD_ROOT/%{_infodir}/dir

Things build after that.  rpmlint then says:
  librep.x86_64: W: incoherent-version-in-changelog 0.17-2 
   0.17-2.svn20071102.fc9
Your changelog entries should match the version.

  librep-devel.x86_64: W: no-documentation
This is OK, but you should consider whether any of the documentation you package
is more appropriate for the -devel package.

I notice a bunch of .la files packaged.  Generally these should not be packaged;
do you have some specific reason for doing so?

Are the .jl and .jlc files arch-neutral?  Otherwise they will conflict when both
i386 and x86_64 packages are installed together.

There'a a bunch of stuff installed into /usr/libexec/rep that seems better
suited to %{_libdir}/rep instead.  Generally I'd expect to see only executables
in /usr/libexec. (See what gcc does, for example.)  I do not know if this
opinion is widely held, however.
Comment 2 Michal Jaegermann 2008-02-02 20:41:39 EST
Created attachment 293814 [details]
modified librep spec file

Some further remarks about this package:

.svn .cvsignore are superflous in a tar file.
Every file and directory in a tar file
has the same timestamp (possibly an svn deficiency).
/sbin/install-info is 'Prereq:' to install documentation
gmp should be in 'Requires:'

In %files section it should be just

%{_datadir}/rep
%{_libexecdir}/rep
%{_datadir}/emacs/site-lisp/*

or you will get "leftovers" after deinstalling the package

%{_datadir}/emacs/site-lisp/*
%{_infodir}/*.info*

possibly in 'devel'

Options for %configure are taken from old librep specs.
I cannot tell how necessary they are now but they definitely
work.  Missing '--with-readline' is not good.

Modified spec file is attached.
Comment 3 Jason Tibbitts 2008-02-02 21:33:37 EST
Please note that use of Prereq: is not allowed and is a blocker.  Requires(pre):
is probably what is intended, although it seems that other dependencies are a
bit off in the specfile from comment #2 (Requires(post): /sbin/ldconfig,
/sbin/install-info is missing, for example.)

For things like this you should just consult
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets and use the scriptlets
and dependencies provided there.

Also, I noticed that the name of the package violates the naming guidelines. 
"svnYYYYMMDD" is incorrect; the date goes first, followed by whatever you like
(probably "svn" in this case).
Comment 5 Michal Jaegermann 2008-02-03 17:08:18 EST
Thanks for corrections in comment #3.  I just looked at some
"historical" packages and not on wiki. :-)

BTW, after

find . -name .svn | xargs rm -rf
find . -name .cvsignore | xargs rm
rm -rf autom4te.cache

in librep-0.17 directory a size of the original source archive drops
down by roughly 2/3rd without, of course, affecting a compilation in
any way and size differences in a resulting src.rpm are of a similar
order.
Comment 6 ritz 2008-02-27 09:42:01 EST
Kool. Thanks, updated

http://people.redhat.com/rkhadgar/personal/fedora/librep.spec
http://people.redhat.com/rkhadgar/personal/fedora/librep-0.17-4.20071102svn.fc9.src.rpm

Hitting one issue though. How do i build "librep-common" for noarch ? Using
"BuildArch: noarch" with librep-common yields lots of error :(

Comment 7 Michal Jaegermann 2008-02-27 18:34:02 EST
> How do i build "librep-common" for noarch ?

You are putting in "librep-common" a lot of byte-compiled .jlc files.
Are you really sure that they are the same for all possible architectures?

In any case it does not seem possible to specify "BuildArch" for a
subpackage _on the same build_.  The same source with two different
spec files and building twice could do it.

If I am mistaken somebody will tell me, I presume. :-)  You would need
"BuildArch: %{_arch}" for other subpackages - would be my guess
(but that seems to override BuildArch settings for "common").
Comment 8 ritz 2008-02-28 04:29:46 EST
> You are putting in "librep-common" a lot of byte-compiled .jlc files.
> Are you really sure that they are the same for all possible architectures?
" As for .jlc's, I've been shipping them in an arch-neutral package in
Debian for over a year now, and nothing has broken since, so I guess they
are ;) "

http://mail.gnome.org/archives/sawfish-list/2008-February/msg00013.html
Comment 9 Michal Jaegermann 2008-02-28 11:17:40 EST
> "... and nothing has broken since ..."

That is a good hint but a pretty weak argument, appearences to the contrary.
If those files were used mostly for i386 and x86_64 then there are many
similarities here, including endianess.  Checking in sources that a byte
compiler is indeed arch-independent would be a different matter.

I looked through installed "noarch" packages on one system and peeked
at such few which could be a subpackage; like 'gimp-help', for example.
They all appear to build separately; so this seems to support what
I said in comment #7.  OTOH is there really any good reason for somebody
to try to install sawfish.i386 and sawfish.x86_64 at the same time
which would require two variants of librep and would cause conflicts
on files from "common"?  I do not see any but possibly I miss something.
Comment 10 ritz 2008-04-10 02:21:57 EDT
the jlc file are the same, atleast across i386,ia64, and ppc64.

update spec file to include libtool in build dependency.
Comment 11 ritz 2008-04-17 01:51:12 EDT
based on my understanding, i dont see any reason for a person to install both
i386 and x86_64 version, in my box. will merge back librep-common into librep.

 librep is a scripted language, and relevant bindings to run all know
application (to me) can be installed natively on x86_64.
Comment 13 Jason Tibbitts 2008-06-18 20:24:56 EDT
Doesn't look like Ritesh is in cvsextras yet.

This package builds fine and rpmlint only complains about the lack of docs in
librep-devel.

/usr/share/aclocal seems to be unowned.  I think the -devel package needs a
dependency on automake.

If you're going to package a subversion checkout, please see
http://fedoraproject.org/wiki/Packaging/SourceURL for info on including
instructions for duplicating the checkout.  I need to be able to check out my
own copy of the upstream source by following information in the specfile.

Honestly I'd say this package is pretty close now, but I haven't done a complete
review.
Comment 15 Patrice Dumas 2008-07-12 05:56:20 EDT
The checkout instructions should include a date or a -r switch
such that the same tarble is constructed even if there has been
some later changes in the svn.

The release is not right, it should be
Release:        0.3.%{snapshot}%{?dist}

You should not use gzip on the info files, it is done automatically.

A dot is missing at the end of the -devel %description.

The --with-malloc-alignment=8 for specific arches is very scary and 
doesn't scale well. Isn't it possible to achieve portability? 

I suggest not having -f for the 2 first rm, such that you notice when the
files are not installed anymore. It should stay for
$RPM_BUILD_ROOT%{_infodir}/dir since it may or may not be created depending on
the situation. This would lead to

rm $RPM_BUILD_ROOT%{_libdir}/*.la
rm $RPM_BUILD_ROOT%{_libdir}/rep/%{version}/%{_host}/*.la
rm -f $RPM_BUILD_ROOT%{_infodir}/dir

There is a missing
Requires(post): /sbin/ldconfig

Also a missing Requires: automake for the devel package, or, alternatively
owning %{_datadir}/aclocal/.

A suggestion, I think it is nice to have a trailing / for directories
in %files to see that they are directories. It is just a personal preference,
though. This would lead to

%{_datadir}/rep/

and

%{_libdir}/rep/

Since there are emacs files, you should certainly follow
http://fedoraproject.org/wiki/Packaging/Emacs
and also shouldn't the file also be byte-compiled?

There are these rpmbuild warnings:
warning: File listed twice: /usr/lib/librep.so.9
warning: File listed twice: /usr/lib/librep.so.9.4.0

There are still some .la files in -devel, like
/usr/lib/rep/0.17/i686-pc-linux-gnu/rep/data/tables.la

Aren't the files in /usr/lib/rep/0.17/i686-pc-linux-gnu/ needed for
rep at runtime?


It seems to me that %{_libdir}/rep/ is unowned. 
Comment 16 ritz 2008-08-13 12:48:45 EDT
updated

http://people.redhat.com/rkhadgar/personal/fedora/librep.spec
http://people.redhat.com/rkhadgar/personal/fedora/librep-0.17.1-rc1.src.rpm

is the emacs subpackage really required ? where do i find examples for these, i looked up subversion, libidn from what i could see on my system.

and how do i remove the  message below
librep.x86_64: W: unstripped-binary-or-object <some-libs>
librep.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/rep ['/usr/lib64']


-- ritz
Comment 17 Patrice Dumas 2008-09-03 07:25:57 EDT
There is an example of emacs subpackages in gnuplot.

For the rpath look at the guidelines, unless I am wrong it is
more or less explained there.
Comment 19 Patrice Dumas 2008-09-28 16:35:42 EDT
I think it is better to keep changelog, to track not only changes but 
also their pace, but it is not a big deal.

For the emacs package this is a bit strange. Indeed -el subupackages
are, unless I am wrong, like -devel subpackages. It seems to me that
the 'compiled' emacs module is missing. That being said, I know next 
to nothing about emacs.

pkgconfig dependency is missing for -devel.

rpmlint warnings are harmless in my opinion
librep-devel.i386: W: no-documentation
librep-devel.i386: E: only-non-binary-in-usr-lib
emacs-librep-el.i386: W: no-documentation

The files in devel in /usr/lib/rep/%{_host} seem dubious. Are 
they really of use?
Comment 20 Patrice Dumas 2008-09-28 16:50:10 EDT
Also in librep.pc there is no Libs: entry???
Comment 21 ritz 2008-10-03 17:59:30 EDT
> I notice a bunch of .la files packaged.  Generally these should not be packaged;
> do you have some specific reason for doing so?
need them to build rep-gtk, or anything for that matter with rep. this is needed. added these to devel package.

> Indeed -el subupackages are, unless I am wrong, like -devel subpackages. It 
> seems to me that the 'compiled' emacs module is missing. That being said, I 
> know next to nothing about emacs.
I do not see any reason to build them. is this really required ?


> The files in devel in /usr/lib/rep/%{_host} seem dubious. Are they really 
> of use?
Yes, to build any apps againt rep.

updated package

http://people.redhat.com/rkhadgar/personal/fedora/librep.spec
http://people.redhat.com/rkhadgar/personal/fedora/librep-0.17.2-1.20081003svn.fc9.src.rpm
Comment 22 Patrice Dumas 2008-10-03 18:35:26 EDT
The release is not right for svn snapshots. Should be like 
0.1.20081003svn

Since you use autogen now, I guess that autoconf/automake are needed.

devel should require pkgconfig.

Looks like the %{_libdir}/rep/ directory is unowned.

Using rep in /usr/share, and in bindir is bad, in my opinion. See
http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Use_of_common_namespace

Using librep instead would be right for the directory, and 
something else for the binary. But this has to be done
with upstream.


Regarding the emacs subpackages, my intuition is that with only 
the el package, it just doeosn't work. But i may well be wrong.
I think that even if the emacs packaging is not perfect, this
shouldn't block the review, this is not vital and i am not 
knowlegable enough.
Comment 23 Michal Jaegermann 2008-10-03 18:59:18 EDT
> Regarding the emacs subpackages, my intuition is that with only 
> the el package, it just doeosn't work.

You really do not need .elc packages with emacs at all.
This is only an "optimization" to load things faster
and with nowadays CPUs negligible one (this was not the
case at emacs beginnings).  There was also "undumping"
which ceased to be feasible.

Moreover I know of cases when a presence of .elc packages
really break things, causing some functions to bail out
with complaints about wrong parameters, while removal
of those and leaving only .el files provides a fix.
Comment 24 ritz 2008-10-03 19:11:58 EDT
> Since you use autogen now, I guess that autoconf/automake are needed.

> devel should require pkgconfig.
> Looks like the %{_libdir}/rep/ directory is unowned.
Updated spec and srpm



> Using rep in /usr/share, and in bindir is bad, in my opinion. See
> http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Use_of_common_namespace

> Using librep instead would be right for the directory, and something else for
> the binary. But this has to be done with upstream.
I really doubt, if this will happen anytime soon. Will check this up with upstream maintainer. Additionally, I was unable to locate any other projects, which used rep for name on google search.


> You really do not need .elc packages with emacs at all.
Thanks for the info.
Comment 25 Patrice Dumas 2008-10-03 20:20:49 EDT
Where is the updated srpm?
Comment 27 ritz 2008-10-04 04:04:59 EDT
> Using rep in /usr/share, and in bindir is bad, in my opinion. See
> http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Use_of_common_namespace
debain is using rep itsel, and upstream[1] does not see much value in this change

[1] http://mail.gnome.org/archives/sawfish-list/2008-October/msg00004.html
Comment 29 Patrice Dumas 2008-10-04 05:58:40 EDT
The %{_libdir}/rep/%{version}/ dir seems unowned.

The %version is still wrong, should be 0.X.20081003svn....

I understand why the .la could be needed at runtime for the
dlopened modules, but is really %{_libdir}/librep.la needed
at build time?
Comment 30 ritz 2008-10-04 07:30:14 EDT
> I understand why the .la could be needed at runtime for the
> dlopened modules, but is really %{_libdir}/librep.la needed
> at build time?
fixed.

>The %version is still wrong, should be 0.X.20081003svn....
fixed

http://people.redhat.com/rkhadgar/personal/fedora/librep.spec
http://people.redhat.com/rkhadgar/personal/fedora/librep-0.17.2-0.2.20081003svn.fc9.src.rpm
Comment 31 Patrice Dumas 2008-10-04 12:56:25 EDT
* rpmlint output ignorable: 
librep-devel.i386: W: no-documentation
librep-devel.i386: E: only-non-binary-in-usr-lib
emacs-librep-el.i386: W: no-documentation
X free software, but license should be included
* follow guidelines
* match upstream (checked manually)
* usual .so unuseful provides
X directory %{_libdir}/rep/%{version}/ unowned.

# rpm -qf /usr/lib/rep/0.17.2/
file /usr/lib/rep/0.17.2 is not owned by any package

I would suggest putting AUTHORS MAINTAINERS in %doc. And maybe doc/*.

2 issues marked with X to be fixed before approval.


And also before approval there are multilib issues remaining:

In librep.pc there is no Libs: entry???

The file /usr/bin/rep-config will conflict in multilib settings, 
on fedora it would be better to patch it such that it is a wrapper 
around pkgconfig, and you can submit to upstream the resulting rep-config
script such that they also ship it, and packagers can choose what to 
install.
Comment 32 ritz 2008-10-05 13:03:09 EDT
> The file /usr/bin/rep-config will conflict in multilib settings, 
is multilib support really required ? As i see this to be of little value - comment#11 .


> In librep.pc there is no Libs: entry???
As of now, i am thinking of excluding this from package. Will talk to upstream about this using this as a wrapper around pkgconfig.
Comment 33 Patrice Dumas 2008-10-05 15:47:43 EDT
(In reply to comment #32)
> > The file /usr/bin/rep-config will conflict in multilib settings, 
> is multilib support really required ? As i see this to be of little value -
> comment#11 .

One may want to link against a specific arch. But even though this 
is not a very usefull setting, one should not have get error when 
installing both, and currently this is the case, since there is a 
conflict.
Comment 34 Michal Jaegermann 2008-10-09 00:48:20 EDT
Files in rep/%{version}/%{_host}/ were moved from
%{_libexecdir}/rep/... to %{_libdir}/rep/...
Not sure when, how and what for?  This makes sawfish
specs, ahem, "interesting" as they work or not depending
only on with which version of librep you are trying
to compile without any real interface changes in this
library.  Sawfish will compile but %files section will
change depending on circumstances.  It is possible 
to check in specs where librep in use puts 'rep'
and define %{librepwhere} accordingly to be used
in %files; it looks like an extra bother.

Was this an attempt to make librep and sawfish
"multilib"?  I miss a purpose of such exercise although
maybe there is one?
Comment 35 Patrice Dumas 2008-10-09 05:18:23 EDT
(In reply to comment #34)

> Was this an attempt to make librep and sawfish
> "multilib"?  I miss a purpose of such exercise although
> maybe there is one?

If there is %{_host} it shouldn't be problematic with respect with
multilib (at least regarding file conflicts).
Comment 36 Michal Jaegermann 2008-10-09 10:53:18 EDT
> If there is %{_host} ...
You mean that architecture shows up as a part
of %{_host}?  In that case was the move in question
dictated by other considerations?
Comment 37 Patrice Dumas 2008-10-09 11:32:02 EDT
(In reply to comment #36)
> > If there is %{_host} ...
> You mean that architecture shows up as a part
> of %{_host}?  In that case was the move in question
> dictated by other considerations?

$ rpm --eval %_host
i386-redhat-linux-gnu
Comment 38 ritz 2008-10-14 08:55:09 EDT
I had tried building a multi-lib package before, and ended up with conflict between i386 and x86_64 package. Few of the files are listed below 

/usr/share/rep/0.17.2/lisp/cgi-get.jl
/usr/share/rep/0.17.2/lisp/cgi-get.jlc
/usr/share/rep/0.17.2/lisp/compiler.jl
/usr/share/rep/0.17.2/lisp/compiler.jlc
/usr/share/rep/0.17.2/lisp/date.jl
/usr/share/rep/0.17.2/lisp/date.jlc
/usr/share/rep/0.17.2/lisp/disassembler.jl
/usr/share/rep/0.17.2/lisp/disassembler.jlc
/usr/share/rep/0.17.2/lisp/gaol.jl
/usr/share/rep/0.17.2/lisp/gaol.jlc
/usr/share/rep/0.17.2/lisp/lisp-doc.jl
...

as pointed out by comment#9, i do not see any reason for a person to install both x86_64 , and i386 version on a system.

-------------------------

If otherwise required, i will go ahead and package /usr/share/rep/%{version}/lisp/ under librep-common package. the only question being, how do i build a noarch package ?
Comment 39 Patrice Dumas 2008-10-19 07:25:30 EDT
I you have rpms, I'd like to look at the files to see where differences 
are. I tried a scratch build, but it failed:
https://koji.fedoraproject.org/koji/taskinfo?taskID=888335
Comment 40 ritz 2008-10-20 00:18:51 EDT
sorry, i was unable to access the page.
Comment 41 Patrice Dumas 2008-10-20 16:07:53 EDT
I can access that page...
Comment 42 ritz 2008-10-20 16:43:53 EDT
my bad, i had not installed the cert.
Comment 43 Jonathan Underwood 2008-10-22 13:08:22 EDT
Michal, you need a emacs-%{name} sub-package which contains the byte compiled emacs files (this is distinct from the emacs-%{name}-el subpackage which contains the elsip source files).
Comment 44 Michal Jaegermann 2008-10-22 13:20:39 EDT
> Michal, you need a emacs-%{name} sub-package ...
Eh?  What do you mean by "you need"?  It may be useful for some, although in various cases this is really debatable, but is surely not "needed" if you
have .el files.
Comment 45 Jonathan Underwood 2008-10-22 13:24:22 EDT
(In reply to comment #44)
> > Michal, you need a emacs-%{name} sub-package ...
> Eh?  What do you mean by "you need"?  It may be useful for some, although in
> various cases this is really debatable, but is surely not "needed" if you
> have .el files.

Please see:

https://fedoraproject.org/wiki/Packaging/Emacs
Comment 46 Jonathan Underwood 2008-10-22 13:31:26 EDT
Actually comment #43 was aimed at the package submitter ("ritz") rather than Michal, apologies for that.

But the point stands - byte compilation is necessary, as it provides a speedup when parsing many elisp files (particularly on older machines. Also, if a file doesn't do what it should when byte compiled, then that's a bug.
Comment 47 Michal Jaegermann 2008-11-03 12:01:35 EST
Re comment #6 about building a "noarch subpackages".  A changelog for rpm-4.6.0-0.rc1.7 in the current rawhide includes the following comment:

* Sat Oct 25 2008 Panu Matilainen <pmatilai@redhat.com>
- Make noarch sub-packages actually work

I guess that this leaves you in a cold with earlier rpm versions.  Maybe Panu would have some additional comments; in particular about mechanics of this option.
Comment 48 Jason Tibbitts 2008-11-04 14:28:00 EST
rpm may now support noarch subpackages, but the buildsys doesn't.  Honestly there are some interesting issues that crop up, such as which of the noarch packages gets used?  The one from the i386 build, the x86_64 build, one of the PPC builds, or something else?  There's no guarantee that they're the same; unless significant care is taken they will almost always differ in the timestamps of the included files and may differ in more significant ways.

Bottom line: noarch subpackages do not work and aren't going to work even in F10, regardless of what support has been checked into rpm.
Comment 49 Jason Tibbitts 2008-12-22 15:37:10 EST
So what's up with this ticket?  The last comment from the submitter was a comple of months ago.  As for the emacs stuff, I would suggest that you follow the emacs packaging guidleines if you intend to package the emacs stuff, but other packages have simply taken the step of packaging a lone .el file as documentation and leaving it to the end user to set that up if they want it.

Also, the package in comment #30, which seems to be the most recent one, fails to build for me in rawhide:

Running aclocal
Running autoconf
configure: WARNING: unrecognized options: --disable-rpath
configure: error: cannot run /bin/sh ./config.sub
Comment 50 Michal Jaegermann 2008-12-22 20:35:15 EST
> Also, the package in comment #30, which seems to be the most recent one,

The package may be the most recent one but the current _releases_ are
librep 0.17.2: http://sourceforge.net/project/showfiles.php?group_id=580
rep-gtk 0.18.3: http://sourceforge.net/project/showfiles.php?group_id=581
and
sawfish 1.3.5: http://sourceforge.net/project/showfiles.php?group_id=32

The first two were released 2008-10-22 and sawfish on 2008-12-20.
Comment 51 Jason Tibbitts 2009-02-11 14:19:05 EST
It's been many months since the last comment from the submitter of this ticket; I will close this out in a week if progress isn't made.
Comment 52 Jason Tibbitts 2009-03-09 20:07:36 EDT
Well, I waited a month.  Closing.
Comment 53 Jason Tibbitts 2011-03-31 15:33:29 EDT

*** This bug has been marked as a duplicate of bug 692537 ***