Spec URL: http://salimma.fedorapeople.org/for_review/gnustep/gnustep-base.spec SRPM URL: http://salimma.fedorapeople.org/for_review/gnustep/gnustep-base-1.16.3-2.fc10.src.rpm Description: The GNUstep Base Library is a powerful fast library of general-purpose, non-graphical Objective C classes, inspired by the superb OpenStep API but implementing Apple and GNU additions to the API as well. It includes for example classes for unicode strings, arrays, dictionaries, sets, byte streams, typed coders, invocations, notifications, notification dispatchers, scanners, tasks, files, networking, threading, remote object messaging support (distributed objects), event loops, loadable bundles, attributed unicode strings, xml, mime, user defaults. This package includes development headers too.
Don't have time to do a full review just now, but I note that the BuildRequires for docs such as: tetex-latex should probably be replaced with the virtual 'tex(latex)' Requires, since F-9 and later use texlive not tetex. If you end up building on F-8, this may have to be conditionalised.
Tried the test programs that come with gnustep-base, also some of my own code that uses gnustep-base functionality, most everything looks like it is working. The only possible issue I saw was gdomap, the distributed objects functionality may not be operational.
taking for review, I want to see oolite in fedora.
There seems to be a missing BR for some ssl-devel: checking openssl/ssl.h usability... no checking openssl/ssl.h presence... no checking for openssl/ssl.h... no configure: WARNING: SSL bundle will not be built: Could not find openssl libraries Is this intentional? Because if it builds with it, it should be included. Ref: devel 1. Why is "/usr/include/gnu-gnu-gnu" used as directory for include files (in -devel) ? I'd say that /usr/include/gnustep would look more "normal". After a quick glance over http://www.gnustep.org/experience/documentation.html I have not found any reference for "gnu-gnu-gnu". 2. %{_libdir}/GNUstep/Makefiles/ and /usr/lib64/GNUstep/Makefiles/Additional/ are unowned Ref: base I have built the package in mock on an x86_64 and I think that there are some issues: 3. Why is /usr/lib/x86_64/linux-gnu/gnu-gnu-gnu/ used and not /usr/lib64/gnustep ? 4. The name "pl" (/usr/bin/pl) is not really acceptable, under the terms of http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Use_of_common_namespace 5. docs should be built by default unless there is a very compelling reason to not do it. rpmlint has also a complaint about mixed use of spaces and tabs, please be as kind as to fix it.
At the first glance, the license should be LGPL v2. This is specified both in [most of ] the source files and in the README file. What is the reasoning behind using GPLv3+ in the spec ?
*** Bug 475852 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > Ref: devel > 1. Why is "/usr/include/gnu-gnu-gnu" used as directory for include files (in > -devel) ? I'd say that /usr/include/gnustep would look more "normal". After a > quick glance over http://www.gnustep.org/experience/documentation.html I have > not found any reference for "gnu-gnu-gnu". > 2. %{_libdir}/GNUstep/Makefiles/ and /usr/lib64/GNUstep/Makefiles/Additional/ > are unowned I have done some rework with gnustep-make-2.0.6-14 which may effected this review. It may be nice if you can checked it out. The deffences are: 1.) Removing of the gnu-gnu-gnu libcombol stuff 2.) Make sure the *.so files will going into /usr/lib64 instead of /usr/lib
(In reply to comment #5) > At the first glance, the license should be LGPL v2. This is specified both in > [most of ] the source files and in the README file. What is the reasoning > behind using GPLv3+ in the spec ? The tools should be licensed under the GPL instead of the LGPL for the libraries.
(In reply to comment #0) > Spec URL: http://salimma.fedorapeople.org/for_review/gnustep/gnustep-base.spec > SRPM URL: > http://salimma.fedorapeople.org/for_review/gnustep/gnustep-base-1.16.3-2.fc10.src.rpm I will notify that 1.16.5 is the current relase now.
Michel, please comment on the above or I am going to close this bug and review the one submitted by Jochen
Michel, ping ?
This is the final ping on this bug. If in one week time I get no reply, I am going to close this one as NOTABUG and reopen Bug 475852.
Since - we had no reply from the OP since it was submitted, despite several suggestions and pings - we have another active bug for the same package, I am closing this one. *** This bug has been marked as a duplicate of bug 475852 ***