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
Summary: | Review Request: libFoundation - A free implementation of OpenStep's Foundation Kit | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Axel Thimm <axel.thimm> |
Component: | Package Review | Assignee: | Dominik 'Rathann' Mierzejewski <dominik> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Package Reviews List <fedora-package-review> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | axel.thimm, jochen, rdieter, toshio |
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: | 2006-11-02 18:10:23 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 197649 | ||
Bug Blocks: | 163779 |
Description
Axel Thimm
2006-08-02 05:41:06 UTC
I'll review this, too, since it depends on #197649. Shouldn't this block FE-REVIEW instead of FC-REVIEW? I don't think this is destined for core quite yet. It should, my mistake. 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? 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. (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. 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? > 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.
(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? 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. 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. 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? (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. (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 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. Over two weeks have passed and the package is still not built for FC-5. *ping* Builds for FC-5 have been just queued, closing as NEXTRELEASE. 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). 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. 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! |