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.
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.
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.
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).
Updates posted based on feedback from Jason and Michal http://people.redhat.com/rkhadgar/personal/fedora/librep.spec http://people.redhat.com/rkhadgar/personal/fedora/librep-0.17-3.20071102svn.fc8.src.rpm
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.
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 :(
> 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").
> 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
> "... 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.
the jlc file are the same, atleast across i386,ia64, and ppc64. update spec file to include libtool in build dependency.
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.
downgraded the spec & srpm file http://people.redhat.com/rkhadgar/personal/fedora/librep.spec http://people.redhat.com/rkhadgar/personal/fedora/librep-0.17-3.20071102svn.fc9.src.rpm
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.
this is a svn pull of the stack, updated http://people.redhat.com/rkhadgar/personal/fedora/librep.spec http://people.redhat.com/rkhadgar/personal/fedora/librep-0.17-3.20071102svn.fc9.src.rpm
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.
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
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.
updated. thanks for the inputs. http://people.redhat.com/rkhadgar/personal/fedora/librep.spec http://people.redhat.com/rkhadgar/personal/fedora/librep-0.17.1-1.src.rpm -- ritz
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?
Also in librep.pc there is no Libs: entry???
> 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
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.
> 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.
> 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.
Where is the updated srpm?
here - 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
> 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
updated package http://people.redhat.com/rkhadgar/personal/fedora/librep.spec http://people.redhat.com/rkhadgar/personal/fedora/librep-0.17.2-2.20081003svn.fc9.src.rpm
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?
> 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
* 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.
> 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.
(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.
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?
(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).
> 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?
(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
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 ?
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
sorry, i was unable to access the page.
I can access that page...
my bad, i had not installed the cert.
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).
> 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.
(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
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.
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> - 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.
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.
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
> 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.
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.
Well, I waited a month. Closing.
*** This bug has been marked as a duplicate of bug 692537 ***