Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 201000 - Review Request: libFoundation - A free implementation of OpenStep's Foundation Kit
Summary: Review Request: libFoundation - A free implementation of OpenStep's Foundatio...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dominik 'Rathann' Mierzejewski
QA Contact: Fedora Package Reviews List
URL:
Whiteboard:
Depends On: 197649
Blocks: FE-ACCEPT
TreeView+ depends on / blocked
 
Reported: 2006-08-02 05:41 UTC by Axel Thimm
Modified: 2010-07-05 21:50 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-11-02 18:10:23 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Axel Thimm 2006-08-02 05:41:06 UTC
Spec URL: http://people.atrpms.net/~athimm/fedorasubmit/libFoundation/libFoundation.spec
SRPM URL: http://people.atrpms.net/~athimm/fedorasubmit/libFoundation/libFoundation-1.1.3-8.at.src.rpm
Description:
libFoundation is a free and almost complete implementation of
Foundation Kit as defined by the OpenStep specifications, plus more
classes that come with the newest releases of OPENSTEP 4.x and
Rhapsody.

Expected rpmlint output:
W: libFoundation invalid-license libFoundation license
W: libFoundation-devel no-documentation

Comment 1 Dominik 'Rathann' Mierzejewski 2006-08-09 22:05:51 UTC
I'll review this, too, since it depends on #197649.

Comment 2 Jason Tibbitts 2006-08-10 00:14:33 UTC
Shouldn't this block FE-REVIEW instead of FC-REVIEW?  I don't think this is
destined for core quite yet.

Comment 3 Dominik 'Rathann' Mierzejewski 2006-08-10 00:16:50 UTC
It should, my mistake.

Comment 4 Dominik 'Rathann' Mierzejewski 2006-09-10 19:23:10 UTC
Here we go:

1. package meets naming and packaging guidelines.
2. specfile is properly named, is cleanly written and uses macros consistently.
3. dist tag is present.
4. build root is sane, though not the recommended one
5. license field matches the actual license.
6. ??? license is open source-compatible. License text included in package.
7. source files match upstream:
7df921ab5705af28a75e62a3a8744cb6  libFoundation-1.1.3-r155.tar.gz
8. latest version is being packaged.
9. BuildRequires are proper.
10. package builds in mock ( ).
11. rpmlint warnings as expected.
12. final provides and requires are sane:

libFoundation.so.1.1()(64bit)
libFoundation = 1.1.3-8
=
/sbin/ldconfig
libFoundation.so.1.1()(64bit)
libc.so.6()(64bit)
libdl.so.2()(64bit)
libm.so.6()(64bit)
libobjc.so.1()(64bit)

libFoundation-devel = 1.1.3-8
=
gcc-objc
gnustep-make
libFoundation = 1.1.3-8

13. shared libraries are present and ldconfig is called as appropriate
14. package is not relocatable.
15. owns the directories it creates.
16. doesn't own any directories it shouldn't.
17. duplicates in %files:
warning: File listed twice: /usr/include/Foundation
warning: File listed twice: /usr/include/Foundation/Foundation.h
...
warning: File listed twice: /usr/include/Foundation/UnixSignalHandler.h
warning: File listed twice: /usr/include/Foundation/exceptions
warning: File listed twice:
/usr/include/Foundation/exceptions/EncodingFormatExceptions.h
...
warning: File listed twice: /usr/include/Foundation/exceptions/StringExceptions.h
warning: File listed twice: /usr/include/extensions
warning: File listed twice: /usr/include/extensions/DefaultScannerHandler.h
...
warning: File listed twice: /usr/include/extensions/support.h
warning: File listed twice: /usr/include/lfmemory.h
warning: File listed twice: /usr/include/real_exception_file.h
18. file permissions are appropriate.
19. %clean is present.
20. %check is not present nor necessary
21. no scriptlets present.
22. code, not content.
23. documentation is small, so no -docs subpackage is necessary.
24. %docs are not necessary for the proper functioning of the package.
25. headers in devel
26. no pkgconfig files.
27. no libtool .la droppings.
28. not a GUI app.
29. not a web app.

Please fix 17. Is the license OSI-approved?


Comment 5 Axel Thimm 2006-09-11 18:42:35 UTC
Thanks, I'll fix 17. Wrt license: It looks rather BSD-like (w/o attribution),
but has some rewording. So I wouldn't call it OSI-approved, but it's otherwise
an open source license as required.


Comment 6 Ralf Corsepius 2006-09-15 02:40:05 UTC
(In reply to comment #4)
>
> warning: File listed twice: /usr/include/extensions
> warning: File listed twice: /usr/include/extensions/DefaultScannerHandler.h
> ...
> warning: File listed twice: /usr/include/extensions/support.h
> warning: File listed twice: /usr/include/lfmemory.h
> warning: File listed twice: /usr/include/real_exception_file.h

Yet another case of a package polluting /usr/include.

IMO, /usr/include/extensions definitely is too general to be acceptable, the
headers in /usr/include/ are arguable.

I strongly recommend to move all /usr/include/* to a subdirectory.




Comment 7 Toshio Kuratomi 2006-09-15 17:50:04 UTC
In addition to the simple pollution of /usr/include, since this is one possible
implementation of part of the OpenStep specification, does it make sense to
namespace things with some sort of upstream vendor directory?  Or is it going to
be an "official" implementation of OpenStep's FoundationKit on Linux?

Comment 8 Rex Dieter 2006-09-15 18:11:25 UTC
> since this is one possible
> implementation of part of the OpenStep specification

I *seriously* doubt we will ever see another implementation (at least in our 
lifetimes...) (;  Let's not invent solutions for problems that don't (yet) 
exist.

Comment 9 Dominik 'Rathann' Mierzejewski 2006-09-21 18:53:55 UTC
(In reply to comment #6)
> Yet another case of a package polluting /usr/include.
> 
> IMO, /usr/include/extensions definitely is too general to be acceptable, the
> headers in /usr/include/ are arguable.
> 
> I strongly recommend to move all /usr/include/* to a subdirectory.

I'm inclined to agree. Axel?



Comment 10 Axel Thimm 2006-09-21 19:13:32 UTC
Spec URL:
http://people.atrpms.net/~athimm/fedorasubmit/libFoundation/libFoundation.spec
SRPM URL:
http://people.atrpms.net/~athimm/fedorasubmit/libFoundation/libFoundation-1.1.3-10.at.src.rpm

* Wed Sep 20 2006 Axel Thimm <Axel.Thimm> - 1.1.3-10
- With the FHS changes some %%_includedir entries appeared as duplicates.

Addresses the open issues from comment #4. Wrt to moving includedirs around I
prefer not to.


Comment 11 Dominik 'Rathann' Mierzejewski 2006-09-27 17:23:27 UTC
After some consideration, I've decided to ask you to move
/usr/include/extensions to, say, /usr/include/Foundation/extension. The name
*is* too generic and even X11 has its extensions/ dir in /usr/include/X11.

Comment 12 Axel Thimm 2006-09-28 20:51:08 UTC
I'm not sure what impact this would have on other dependent projects, and it's
for fixing something that (currently) isn't broke. I also consulted the
packaging commitee and most agree on that (but we were only 5 out of 10 present).

I suggest the following: Let the package pass as is (at least wrt to headers, if
the are other issues, they need to be fixed, of course), and I will take the
header topic upstream. So should a clash with say glibc's assumed future
extensions folder come up, the issue would have been ironed out at the source
and not the package. Do you agree?



Comment 13 Ralf Corsepius 2006-09-29 02:26:39 UTC
(In reply to comment #12)
> I'm not sure what impact this would have on other dependent projects, and it's
> for fixing something that (currently) isn't broke. I also consulted the
> packaging commitee and most agree on that (but we were only 5 out of 10
> present).
Sorry, due to an unplanned commitment, I could not make it yesterday.
If I had been around, I would have voted against "allowing /usr/include/extensions"

> I suggest the following: Let the package pass as is (at least wrt to headers, if
> the are other issues, they need to be fixed, of course), and I will take the
> header topic upstream. So should a clash with say glibc's assumed future
> extensions folder come up, the issue would have been ironed out at the source
> and not the package. Do you agree?

I don't fully understand what you are trying to say, but the answer probable is
"no".

IMO, THIS package is misbehaving and therefore MUST be fixed. If other packages
contain hard-coded dependencies on this misbehavior, all necessary changes MUST
be reflected to them, too.

Comment 14 Dominik 'Rathann' Mierzejewski 2006-10-13 18:16:04 UTC
(In reply to comment #12)
> I'm not sure what impact this would have on other dependent projects, and it's
> for fixing something that (currently) isn't broke.

IMHO this is avoiding future trouble.

> I also consulted the packaging commitee and most agree on that (but we were
> only 5 out of 10 present).

3/10 is hardly a majority.

> I suggest the following: Let the package pass as is (at least wrt to headers,
> if the are other issues, they need to be fixed, of course), and I will take
> the header topic upstream. So should a clash with say glibc's assumed future
> extensions folder come up, the issue would have been ironed out at the source
> and not the package. Do you agree?

No, I don't, but I'm not going to hold this up. If anyone has some issues later,
I'll tell them to take it up with you four.

APPROVED

Comment 15 Axel Thimm 2006-10-13 18:55:12 UTC
Thanks Dominik!

FWIW it wasn't 3/10, but all 5 present members agreed on that. If something
breaks in the future, it will get fixed, of course.

Comment 16 Dominik 'Rathann' Mierzejewski 2006-11-01 12:00:56 UTC
Over two weeks have passed and the package is still not built for FC-5. *ping*

Comment 17 Axel Thimm 2006-11-02 18:10:23 UTC
Builds for FC-5 have been just queued, closing as NEXTRELEASE.


Comment 18 Axel Thimm 2010-07-05 19:30:24 UTC
Package Change Request
======================
Package Name: libFoundation
New Branches: remove package

The package was introduced as a dependency for OGo, but the latter never made it to the repo. Currently the package requires special handling of coinstallation policies in order to allow gnustep parts into Fedora. There have been requests to remove the package, which is probably the right thing to do atm.

See also bug #531899

Wrt procedure: I'm following https://fedoraproject.org/wiki/CVS_admin_requests which is newer than https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
Both address the topic of removing a package in different ways (CVS admin request vs dead.package and new bugzilla request).

Comment 19 Kevin Fenzi 2010-07-05 19:51:23 UTC
Please follow https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

I will fix the admin requests page. 

The only time we really remove a package like that is when it has non free content or some other drastic problem, otherwise we want the package to exist in cvs history and such.

Comment 20 Axel Thimm 2010-07-05 21:50:50 UTC
Actually the devel and F-13 branches had already been taken care of, I had just forgotten and the bug report in #531899 the package was still alive. Sorry for the red herring!


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