Bug 459210 - Review Request: gnustep-base - GNUstep base package
Review Request: gnustep-base - GNUstep base package
Status: CLOSED DUPLICATE of bug 475852
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: manuel wolfshant
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-14 21:22 EDT by Michel Alexandre Salim
Modified: 2009-09-24 07:54 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-14 17:56:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
wolfy: fedora‑review-


Attachments (Terms of Use)

  None (edit)
Description Michel Alexandre Salim 2008-08-14 21:22:20 EDT
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.
Comment 1 Alex Lancaster 2008-09-29 03:19:14 EDT
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.
Comment 2 Scott Christley 2008-09-30 01:44:52 EDT
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.
Comment 3 manuel wolfshant 2008-12-05 19:10:01 EST
taking for review, I want to see oolite in fedora.
Comment 4 manuel wolfshant 2008-12-05 19:35:11 EST
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.
Comment 5 manuel wolfshant 2008-12-06 09:56:25 EST
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 ?
Comment 6 Jason Tibbitts 2008-12-10 15:13:31 EST
*** Bug 475852 has been marked as a duplicate of this bug. ***
Comment 7 Jochen Schmitt 2008-12-10 15:37:05 EST
(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
Comment 8 Jochen Schmitt 2008-12-10 15:44:08 EST
(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.
Comment 9 Jochen Schmitt 2008-12-10 15:45:35 EST
(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.
Comment 10 manuel wolfshant 2008-12-21 13:30:02 EST
Michel, please comment on the above or I am going to close this bug and review the one submitted by Jochen
Comment 11 manuel wolfshant 2009-01-03 13:14:16 EST
Michel, ping ?
Comment 12 manuel wolfshant 2009-01-08 22:20:13 EST
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.
Comment 13 manuel wolfshant 2009-01-14 17:56:40 EST
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 ***

Note You need to log in before you can comment on or make changes to this bug.