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
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!