Fedora Merge Review: rpm http://cvs.fedora.redhat.com/viewcvs/devel/rpm/ Initial Owner: pnasrat
OK - Package meets naming and packaging guidelines OK - Spec file matches base package name. OK - Spec has consistant macro usage. OK - Meets Packaging Guidelines. OK - License (GPL) OK - License field in spec matches See below - License file included in package OK - Spec in American English OK - Spec is legible. OK - Sources match upstream md5sum: e24ce468082479fe850c9d6563f56db5 rpm-4.4.2.tar.gz e24ce468082479fe850c9d6563f56db5 rpm-4.4.2.tar.gz.1 See below - BuildRequires correct See below - Spec handles locales/find_lang OK - Package is relocatable and has a reason to be. OK - Package has %defattr and permissions on files is good. OK - Package has a correct %clean section. See below - Package has correct buildroot OK - Package is code or permissible content. OK - Packages %doc files don't affect runtime. OK - Headers/static libs in -devel subpackage. OK - Spec has needed ldconfig in post and postun OK - .so files in -devel subpackage. OK - -devel package Requires: %{name} = %{version}-%{release} OK - .la files are removed. OK - Package compiles and builds on at least one arch. OK - Package has no duplicate files in %files. OK - Package doesn't own any directories other packages own. OK - Package owns all the directories it creates. See below - No rpmlint output. See below - final provides and requires are sane: SHOULD Items: OK - Should build in mock. OK - Should build on all supported archs OK - Should function as described. OK - Should have sane scriptlets. OK - Should have subpackages require base package with fully versioned depend. OK - Should have dist tag OK - Should package latest version 147 outstanding open bugs - check for outstanding bugs on package. 1. There are a number of different liceses here: main part - GPL and some LGPL db - BSDish zlib - weird zlib license. I assume they can all handle being released GPL as a whole? Can you include a copy of the GPL COPYING file? 2. Is there any way that find_lang could be used? I guess it would need to be called from the local ./scripts/find-lang.sh ? 3. Please use the one true buildroot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) 4. Are all the "%ifos linux" conditionals needed? Is this spec used on non linux systems very often? 5. Per http://www.fedoraproject.org/wiki/PackagingDrafts/Conflicts (which is only a draft it's true), could you change the Conflicts: patch < 2.5 to Requires: patch > 2.5 or since this has been true since fc1, can we just remove that? Also in the -build subpackage there's a 'Requires: patch >= 2.5' 6. BuildRequires: sed isn't needed, thats in the base build exceptions. 7. What does the "#XXX: lua fix this" comment mean? 8. Can this conditional be removed now: # XXX Red Hat 5.2 has not bzip2 or python %if %{with_bzip2} 9. In both build and install there is: # XXX rpm needs functioning nptl for configure tests unset LD_ASSUME_KERNEL || : Perhaps instead it could bomb out of the build if someone is stupid enough to have that set these days? Right now if they do have it set and they build rpm, it will magically be unset after the build. 10. Since there's a cron.daily file, shouldn't there also be Requires: crontab 11. Likewise for logrotate, should there be a 'Requires: logrotate' 12. This block in install doesn't seem to be doing anything: %if %{with_apidocs} gzip -9n apidocs/man/man*/* || : %endif from build.log: + gzip -9n 'apidocs/man/man*/*' gzip: apidocs/man/man*/*: No such file or directory The directory in the devel subpackage is empty. 13. The python subpackage should not need to call ldconfig on post/postun. This block can be removed: %if %{with_python_subpackage} %post python -p /sbin/ldconfig %postun python -p /sbin/ldconfig %endif 14. rpmlint has a few things to say: First, there are 240 lines of 'non-standard-uid' or 'non-standard-gid' These can all be ignored in this case. a) W: popt no-url-tag W: rpm no-url-tag W: rpm-build no-url-tag W: rpm-libs no-url-tag W: rpm-python no-url-tag W: rpm-devel no-url-tag Suggest: add a "URL: http://www.rpm.org" ? b) W: popt summary-ended-with-dot A C library for parsing command line parameters. W: rpm summary-ended-with-dot The RPM package management system. W: rpm summary-ended-with-dot The RPM package management system. W: rpm-build summary-ended-with-dot Scripts and executable programs used to build packages. W: rpm-devel summary-ended-with-dot Development files for manipulating RPM packages. W: rpm-libs summary-ended-with-dot Libraries for manipulating RPM packages. W: rpm-python summary-ended-with-dot Python bindings for apps which will manipulate RPM packages. Suggest: remove . at end of summary. c) W: popt devel-file-in-non-devel-package /usr/lib64/libpopt.a W: popt devel-file-in-non-devel-package /usr/include/popt.h W: popt devel-file-in-non-devel-package /usr/lib64/libpopt.so There's a comment that says: # XXX These may end up in popt-devel but it hardly seems worth the effort. %{__libdir}/libpopt.a %{__libdir}/libpopt.so %{__includedir}/popt.h Is it still not worth the effort? Or perhaps now is a good time? Or perhaps they can just be removed if nothing is using them? d) W: rpm prereq-use fileutils shadow-utils fileutils was replaced a while back with coreutils, which is in the min build root exceptions. For shadow-utils, you could do: Requires(pre): shadow-utils Requires(postun): shadow-utils e) W: rpm macro-in-%changelog ghost Suggest: Change "%ghost" in the changelog to "%%ghost" f) W: rpm mixed-use-of-spaces-and-tabs (spaces: line 267, tab: line 1) Suggest: pick tabs or spaces. g) W: rpm patch-not-applied Patch9: rpm-4.4.2-contextverify.patch W: rpm patch-not-applied Patch12: rpm-4.4.2-exclude.patch Suggest: should those patches just be removed? h) E: rpm obsolete-not-provided rpm-perl Suggest: Do we need to have this obsolete around anymore? i) W: rpm file-not-utf8 /usr/share/man/sk/man8/rpm.8.gz W: rpm file-not-utf8 /usr/share/man/pl/man8/rpm.8.gz W: rpm file-not-utf8 /usr/share/man/pl/man8/rpmbuild.8.gz W: rpm file-not-utf8 /usr/share/man/pl/man8/rpmdeps.8.gz W: rpm file-not-utf8 /usr/share/man/pl/man8/rpmgraph.8.gz W: rpm file-not-utf8 /usr/share/man/pl/man1/gendiff.1.gz W: rpm file-not-utf8 /usr/share/man/pl/man8/rpmcache.8.gz W: rpm file-not-utf8 /usr/share/man/pl/man8/rpm2cpio.8.gz Suggest: Perhaps run iconv on those? j) E: rpm script-without-shebang /usr/lib/rpm/rpm.xinetd Suggest: should this be shipped at all? or installed in /etc/xinetd.d/ ? Or at the very least it should be mode 644. k) E: rpm script-without-shebang /usr/lib/rpm/rpm.log Suggest: This is a duplicate of /etc/logrotate.d/rpm, and can be removed? l) E: rpm executable-marked-as-config-file /etc/cron.daily/rpm Suggest: Don't mark that a config file. m) E: rpm-build script-without-shebang /usr/lib/rpm/magic E: rpm-build script-without-shebang /usr/lib/rpm/magic.mime E: rpm-build script-without-shebang /usr/lib/rpm/config.site Suggest: all 3 of those should be mode 644? n) W: rpm-debuginfo spurious-executable-perm /usr/src/debug/rpm-4.4.2/rpmqv.c Suggest: source file should be 644? The following can also be ignored. Since rpm needs rpmmacros to use %configure or the like it can't do that when building itself. Or they otherwise appear to be false positives to me. E: rpm configure-without-libdir-spec E: rpm configure-without-libdir-spec E: rpm hardcoded-library-path in /usr/lib/rpmrc E: rpm standard-dir-owned-by-package /var/lib/rpm W: rpm-libs no-documentation W: rpm-python no-documentation W: rpm dangerous-command-in-%pre rpm W: rpm dangerous-command-in-%post chown W: rpm dangerous-command-in-%postun userdel E: rpm-build statically-linked-binary /usr/lib/rpm/debugedit E: rpm-python script-without-shebang /usr/lib64/python2.5/site-packages/rpm/__init__.py 15. Are all the static libs in -devel needed? If so perhaps a -static subpackage? 16. The 'Requires: python >= %{with_python_version}' isn't needed. rpm adds a 'python(abi) = 2.5' to requires without it. 17. There are currently 147 outstanding open bugs against rpm. You might consider going and doing some triage on them. If you like I would be willing to assist in doing so. Some of them do seem related to packaging concerns. Since there is a upstream at rpm.org, many could possibly be pushed up there (especially patches/enhancement requests). Perhaps we could even round up a QA team session and get them addressed. 18. Is there any chance of trying the sqlite backend? I know it's supposed to be slower than DB, but if it is more reliable it will be well worth it in my opinion. I would also be willing to assist in generating a patch to the spec addressing many of the above if you would like me to. Once you have addressed these items (either by making the suggested changes, or by explaining why they don't make sense), please reassign this review back to me, and change the 'fedora-review' flag back to ? for me to take action.
Per the new review guidelines, resetting flags and such: https://www.redhat.com/archives/fedora-maintainers/2007-February/msg00682.html
FWIW most (but not all) of those issues have been now fixed in 4.4.2-47. But don't bother re-reviewing yet, I'm planning on another major spec cleanup once 4.4.2.1 is out and heading into rawhide.
excellent work! Yeah, please do let me know when it's ready for another look.
Okay, now with popt split out of rpm I think it's time to move forward with this one. Practically all of rpmlint whining against current CVS is from non-standard-[gu]id and other rather rpm specific things such as owning /var/lib/rpm directory. The spec remains a bit of a mess with all the __foodir and _prefix stuff, but I'd rather get rid of those later with next major rpm version that can actually be built using it's own %configure macro, rpm 4.4.2.1 wont survive that, and I've a feeling there are some gotchas lurking in there.
Panu, I already did this job more or less - but for rpm5. It is less pain and seems to work well. If next week matches, my rpm5 package should reach review and then you can copy over bits from there to get the rpm.spec file friendly to rpmlint (of course, there will be some warnings and errors further on, because rpm is a special package).
Stop and sorry! My comment #6 was NOT thought to start any rpm5.org vs. rpm.org discussion. I'm trying to get rpm5.org rpm ready for an add-on package and NOT to replace the current rpm package used in Fedora. If somebody of you tries to complain here about rpm5 in Fedora itself: I already talked with Max Spevack about this and he said, Fedora is open to any package it only has to follow the Fedora Packaging Guidelines to technically match the needs. And IMHO the rest is up to the users.
I think rpm5 in Fedora is dangerous. At the very least it reverses the ordering of letters and digits and thus breaks a ton of packaging techniques. Any *-1.fc8 -> *.1.1.fc8 upgrade path is busted for example.
Please STOP! This rpm(.org) merge review, anything else needs to be discussed elsewhere.
Back to the actual topic: on a second thought, this is as good or bad time as any to do the rest of the cleanup. So hold back with the review for a bit more, I had a large amount of further spec cleanups pending, I might as well finish that up now (and meanwhile let the dust settle a bit from the popt splitout)
Ok, a large spec cleanup done now and rebuilt for rawhide, see latest cvs / rpm-4.4.2.1-10.fc8. And now lets have the real review finally :)
Sorry for the delay on getting back to this... OK - Package meets naming and packaging guidelines OK - Spec file matches base package name. OK - Spec has consistant macro usage. OK - Meets Packaging Guidelines. See below - License (GPLv2+) OK - License field in spec matches OK - License file included in package OK - Spec in American English OK - Spec is legible. OK - Sources match upstream md5sum: 15faa7ebd9791ade1a2f8181821ac259 rpm-4.4.2.2.tar.gz 15faa7ebd9791ade1a2f8181821ac259 rpm-4.4.2.2.tar.gz.1 OK - BuildRequires correct OK - Spec handles locales/find_lang OK - Package has %defattr and permissions on files is good. OK - Package has a correct %clean section. OK - Package has correct buildroot OK - Package is code or permissible content. OK - Doc subpackage needed/used. OK - Packages %doc files don't affect runtime. OK - Package has rm -rf RPM_BUILD_ROOT at top of %install OK - Headers/static libs in -devel subpackage. OK - Spec has needed ldconfig in post and postun OK - .so files in -devel subpackage. OK - -devel package Requires: %{name} = %{version}-%{release} OK - .la files are removed. OK - Package compiles and builds on at least one arch. OK - Package has no duplicate files in %files. OK - Package doesn't own any directories other packages own. OK - Package owns all the directories it creates. See below - No rpmlint output. OK - final provides and requires are sane SHOULD Items: OK - Should build in mock. OK - Should build on all supported archs OK - Should function as described. OK - Should have sane scriptlets. OK - Should have subpackages require base package with fully versioned depend. OK - Should have dist tag OK - Should package latest version 96 open bugs - check for outstanding bugs on package. Issues: 1. Due to the murky pile of licenses, perhaps we could get spot and/or fedora-legal-list to review things to make sure all is well? 2. Could you put in a full URL for the upstream Source? http://rpm.org/releases/rpm-4.4.x/rpm-4.4.2.2.tar.gz ? 3. Just out of curiosity, is popt going to get split out upstream as well? 4. Another idle thought: should /usr/src/redhat be changed? /usr/src/fedora? /usr/src/rpm? 5. Do we still need to ship static libs? 6. rpmlint says: First, there are 264 lines of 'non-standard-uid' or 'non-standard-gid' These can all be ignored in this case. Removing those results in just: a) rpm-apidocs.i386: W: file-not-utf8 /usr/share/doc/rpm-apidocs-4.4.2.2/apidocs/html/build_8c-source.html Suggest: run iconv on it? b) rpm-devel.i386: W: invalid-license LGPLv2+ with exceptions rpm.i386: E: standard-dir-owned-by-package /var/lib/rpm rpm.i386: W: dangerous-command-in-%post rm rpm.i386: W: percent-in-%post rpm-libs.i386: W: invalid-license LGPLv2+ with exceptions rpm-libs.i386: W: no-documentation rpm-python.i386: W: no-documentation rpm.src:169: E: configure-without-libdir-spec rpm.src: W: strange-permission find-debuginfo.sh 0755 Suggest: Ignore. I'd just like to thank you for all the cleanup work you have done on this package. This spec is a vast amount better than the old one. Great work!
1) I've requested legal to comment on the rpm license quite a while ago, haven't heard anything official back. The licensing is complex because of many bundled components but the murkiest part has to do with "lib subdirectory" dual licensing which doesn't really make sense these days. The "GPL/LGPL with exceptions" is about as close as it gets unless the actual license is changed which is another story... 2) The full URL added to cvs now, but it still uses macros for the %{name}-%{version} part, updating the version there manually only leads to stupid mistakes (been there... ;) 3) Yes, popt has been split out in upstream HEAD, but it'll stay in the 4.4.x branch to avoid large changes in maintenance versions. 4) /usr/src/redhat|fedora|packages|rpm needs to die as a concept, we don't want to encourage building packages as root. A saner default setup is needed but it's too late for F8. 5) AFAIK nothing in Fedora needs static rpm libs, guess they could go. 6) The rpmlint whining can indeed be ignored for most part. I'm curious about the file-not-utf8 complaint as doxygen (as of 1.5.2) is supposed to always create UTF-8 for html. The configure-without-libdir-spec is due to rpm configure messing with lib/lib64 itself, preventing the use of --libdir (it'll lead to things like /usr/lib6464 on multilib systems). Fixed in rpm.org HEAD but not going to happen for 4.4.x to avoid breaking legacy expectations in maintenance releases. The biggest remaining question is probably the use of rpm user+group for all sorts of files. Doesn't IMO make much sense, the only place where it might theoretically be useful is rpmdb itself but you can't install anything without being root so...
Created attachment 219891 [details] build.c -> UTF-8 (In reply to comment #13) > I'm curious about > the file-not-utf8 complaint as doxygen (as of 1.5.2) is supposed to always > create UTF-8 for html. rpm's doxygen appears to be configured so that it is told that input source files are in UTF-8. However, the toplevel build.c contains some (partially corrupted) non-UTF-8 commentary which appears to be some strong words in Polish :) http://www.tranexp.com:2000/InterTran?url=http%3A%2F%2F&type=text&text=Kurwa%2C+durni+ameryka%26%23324%3Bce+sobe+zawsze+my%26%23347%3Bl%26%23261%3B%2C+%26%23380%3Be+ca%26%23322%3By+%26%23347%3Bwiat+m%F3wi+po+angielsku&from=pol&to=eng I don't think there's much doxygen can do about this, but if you want to keep that comment, here's a patch which I guess converts it to valid UTF-8 (gzipped so Bugzilla won't corrupt the patch).
Yep, that's in Polish. If you really want to know what exactly it is, it's something like that: "Fuck, dumb Americans always think the whole world speaks English" You should remove that, I guess. ;)
I quote from the review: OK - Spec in American English Some things never change ...
Static libs and the lovely Polish comment :) removed in 4.4.2.2-2 (next rawhide push)
Excellent work. So, really the last issue outstanding that I see is to get the licensing all figured and checked. I'll see we can have spot check...
What's blocking this review? Recent rpmlint does not complain on license because "GPLv2+" and "GPLv2+ and LGPLv2+ with exceptions" are valid now (https://fedoraproject.org/wiki/Licensing). If anyone feels there's problem with licensing, let's block on bug fe-legal. -- Informal rpmlint review on recent rpm ===================================== SPECS/rpm.spec:571: W: macro-in-%changelog patch * Thu Sep 25 2008 Jindrich Novy <jnovy> - don't treat %patch numberless if -P parameter is present (#463942) rpm.src: W: name-repeated-in-summary RPM don't get this one... rpm.src: W: strange-permission fontconfig.prov 0755 rpm.src: W: strange-permission desktop-file.prov 0755 any idea? rpm.x86_64: W: only-non-binary-in-usr-lib "There are only non binary files in /usr/lib so they should be in /usr/share." Huh, what? rpm.x86_64: E: standard-dir-owned-by-package /var/lib/rpm newman@dhcp-lab-124 rpmbuild $ rpmquery -f /var/lib/rpm rpm-4.7.0-0.beta1.9.fc11.x86_64 rpmlint bug? rpm.x86_64: E: script-without-shebang /usr/lib/rpm/rpm.xinetd rpm.x86_64: E: script-without-shebang /usr/lib/rpm/rpm.log exec perm probably not necesary rpm-build.x86_64: E: script-without-shebang /usr/lib/rpm/macros.python rpm-build.x86_64: E: script-without-shebang /usr/lib/rpm/macros.php rpm-build.x86_64: E: script-without-shebang /usr/lib/rpm/macros.perl ditto rpm-python.x86_64: E: script-without-shebang /usr/lib64/python2.6/site-packages/rpm/__init__.py ditto rpm.x86_64: W: dangling-relative-symlink /usr/lib/rpm/rpmdb_recover ../../bin/db_recover rpm.x86_64: W: dangling-relative-symlink /usr/lib/rpm/rpmdb_deadlock ../../bin/db_deadlock rpm.x86_64: W: dangling-relative-symlink /usr/lib/rpm/rpmdb_stat ../../bin/db_stat rpm.x86_64: W: dangling-relative-symlink /usr/lib/rpm/rpmdb_dump ../../bin/db_dump rpm.x86_64: W: dangling-relative-symlink /usr/lib/rpm/rpmdb_archive ../../bin/db_archive rpm.x86_64: W: dangling-relative-symlink /usr/lib/rpm/rpmdb_upgrade ../../bin/db_upgrade rpm.x86_64: W: dangling-relative-symlink /usr/lib/rpm/rpmdb_printlog ../../bin/db_printlog rpm.x86_64: W: dangling-relative-symlink /usr/lib/rpm/rpmdb_verify ../../bin/db_verify rpm.x86_64: W: dangling-relative-symlink /usr/lib/rpm/rpmdb_load ../../bin/db_load rpm.x86_64: W: dangling-relative-symlink /usr/lib/rpm/rpmdb_svc ../../bin/berkeley_db_svc Build system problem? Anyone seeing this too? rpm.x86_64: W: non-standard-uid /var/lib/rpm/Group rpm rpm.x86_64: W: non-standard-gid /var/lib/rpm/Group rpm rpm.x86_64: W: non-standard-uid /var/lib/rpm/Basenames rpm rpm.x86_64: W: non-standard-gid /var/lib/rpm/Basenames rpm rpm.x86_64: W: non-standard-uid /var/lib/rpm/Requireversion rpm rpm.x86_64: W: non-standard-gid /var/lib/rpm/Requireversion rpm rpm.x86_64: W: non-standard-uid /var/lib/rpm/Providename rpm rpm.x86_64: W: non-standard-gid /var/lib/rpm/Providename rpm rpm.x86_64: W: non-standard-uid /var/lib/rpm/__db.007 rpm rpm.x86_64: W: non-standard-gid /var/lib/rpm/__db.007 rpm rpm.x86_64: W: non-standard-uid /var/lib/rpm/Pubkeys rpm rpm.x86_64: W: non-standard-gid /var/lib/rpm/Pubkeys rpm rpm.x86_64: W: non-standard-uid /var/lib/rpm/__db.003 rpm rpm.x86_64: W: non-standard-gid /var/lib/rpm/__db.003 rpm rpm.x86_64: W: non-standard-uid /var/lib/rpm/__db.009 rpm rpm.x86_64: W: non-standard-gid /var/lib/rpm/__db.009 rpm rpm.x86_64: W: non-standard-uid /var/lib/rpm/Conflictname rpm rpm.x86_64: W: non-standard-gid /var/lib/rpm/Conflictname rpm rpm.x86_64: W: non-standard-uid /var/lib/rpm/Provideversion rpm rpm.x86_64: W: non-standard-gid /var/lib/rpm/Provideversion rpm rpm.x86_64: W: non-standard-uid /var/lib/rpm/Triggername rpm rpm.x86_64: W: non-standard-gid /var/lib/rpm/Triggername rpm rpm.x86_64: W: non-standard-uid /var/lib/rpm/Filedigests rpm rpm.x86_64: W: non-standard-gid /var/lib/rpm/Filedigests rpm rpm.x86_64: W: non-standard-uid /var/lib/rpm/Dirnames rpm rpm.x86_64: W: non-standard-gid /var/lib/rpm/Dirnames rpm rpm.x86_64: W: non-standard-uid /var/lib/rpm/__db.004 rpm rpm.x86_64: W: non-standard-gid /var/lib/rpm/__db.004 rpm rpm.x86_64: W: non-standard-uid /var/lib/rpm/__db.005 rpm rpm.x86_64: W: non-standard-gid /var/lib/rpm/__db.005 rpm rpm.x86_64: W: non-standard-uid /var/lib/rpm/__db.001 rpm rpm.x86_64: W: non-standard-gid /var/lib/rpm/__db.001 rpm rpm.x86_64: W: non-standard-uid /var/lib/rpm/__db.002 rpm rpm.x86_64: W: non-standard-gid /var/lib/rpm/__db.002 rpm rpm.x86_64: W: non-standard-uid /var/lib/rpm/Name rpm rpm.x86_64: W: non-standard-gid /var/lib/rpm/Name rpm rpm.x86_64: W: non-standard-uid /var/lib/rpm/__db.008 rpm rpm.x86_64: W: non-standard-gid /var/lib/rpm/__db.008 rpm rpm.x86_64: W: non-standard-uid /var/lib/rpm/Installtid rpm rpm.x86_64: W: non-standard-gid /var/lib/rpm/Installtid rpm rpm.x86_64: W: non-standard-uid /var/lib/rpm/Requirename rpm rpm.x86_64: W: non-standard-gid /var/lib/rpm/Requirename rpm rpm.x86_64: W: non-standard-uid /var/lib/rpm/Sigmd5 rpm rpm.x86_64: W: non-standard-gid /var/lib/rpm/Sigmd5 rpm rpm.x86_64: W: non-standard-uid /var/lib/rpm/Sha1header rpm rpm.x86_64: W: non-standard-gid /var/lib/rpm/Sha1header rpm rpm.x86_64: W: non-standard-uid /var/lib/rpm/Packages rpm rpm.x86_64: W: non-standard-gid /var/lib/rpm/Packages rpm rpm.x86_64: W: non-standard-uid /var/lib/rpm/__db.006 rpm rpm.x86_64: W: non-standard-gid /var/lib/rpm/__db.006 rpm Discussed already. rpm.x86_64: W: dangerous-command-in-%posttrans rm Life's dangerous. rpm-build.x86_64: E: non-executable-script /usr/lib/rpm/perldeps.pl 0644 Investigate please. rpm-libs.x86_64: W: no-documentation rpm-python.x86_64: W: no-documentation Upstream problem :).
> What's blocking this review? As I mentioned in the previous comment, a licensing review. ;) I might have time to sit down and do it this weekend.
(In reply to comment #19) > What's blocking this review? > > Recent rpmlint does not complain on license because "GPLv2+" and "GPLv2+ and > LGPLv2+ with exceptions" are valid now > (https://fedoraproject.org/wiki/Licensing). If anyone feels there's problem > with licensing, let's block on bug fe-legal. BTW rpm's source license has gotten somewhat less complicated since this review was started, as rpm no longer bundles 3rd party libraries in its tarball. So there's basically rpm's main GPL/LGPL dual license + two MIT-licensed Lua extensions. > -- > > Informal rpmlint review on recent rpm > ===================================== > > SPECS/rpm.spec:571: W: macro-in-%changelog patch > > * Thu Sep 25 2008 Jindrich Novy <jnovy> > - don't treat %patch numberless if -P parameter is present (#463942) Ok, will fix. > rpm.src: W: name-repeated-in-summary RPM > > don't get this one... Well it's a pretty bogus warning if you ask me. Rpm's summary contains RPM because it's not only name of the software, it's also name of the package format which the software in question manages. > rpm.src: W: strange-permission fontconfig.prov 0755 > rpm.src: W: strange-permission desktop-file.prov 0755 > > any idea? Another bogus (IMO) warning: these are executable scripts. Why should their permission in the source be anything else? > rpm.x86_64: W: only-non-binary-in-usr-lib > > "There are only non binary files in /usr/lib so they should be in /usr/share." > > Huh, what? Most of /usr/lib/rpm/ contents would be more appropriate for /usr/share/ but changing that is not so simple, lots of things expect rpm scripts and stuff to live in the hardwired /usr/lib/rpm directory. This is not going to change anytime soon. > > rpm.x86_64: E: standard-dir-owned-by-package /var/lib/rpm > > newman@dhcp-lab-124 rpmbuild $ rpmquery -f /var/lib/rpm > rpm-4.7.0-0.beta1.9.fc11.x86_64 > > rpmlint bug? Yes, rpmlint bug. /var/lib/rpm belongs to rpm, not anything else. > > rpm.x86_64: E: script-without-shebang /usr/lib/rpm/rpm.xinetd > rpm.x86_64: E: script-without-shebang /usr/lib/rpm/rpm.log > > exec perm probably not necesary > > rpm-build.x86_64: E: script-without-shebang /usr/lib/rpm/macros.python > rpm-build.x86_64: E: script-without-shebang /usr/lib/rpm/macros.php > rpm-build.x86_64: E: script-without-shebang /usr/lib/rpm/macros.perl > > ditto > > rpm-python.x86_64: E: script-without-shebang > /usr/lib64/python2.6/site-packages/rpm/__init__.py > > ditto Nod, executable permission on all these is incorrect. This is an upstream issue, just fixed it in rpm.org HEAD. Doesn't seem worth bothering to fix in the spec but can/will do if deemed necessary. > > rpm.x86_64: W: dangling-relative-symlink /usr/lib/rpm/rpmdb_recover > ../../bin/db_recover > rpm.x86_64: W: dangling-relative-symlink /usr/lib/rpm/rpmdb_deadlock > ../../bin/db_deadlock > rpm.x86_64: W: dangling-relative-symlink /usr/lib/rpm/rpmdb_stat > ../../bin/db_stat > rpm.x86_64: W: dangling-relative-symlink /usr/lib/rpm/rpmdb_dump > ../../bin/db_dump > rpm.x86_64: W: dangling-relative-symlink /usr/lib/rpm/rpmdb_archive > ../../bin/db_archive > rpm.x86_64: W: dangling-relative-symlink /usr/lib/rpm/rpmdb_upgrade > ../../bin/db_upgrade > rpm.x86_64: W: dangling-relative-symlink /usr/lib/rpm/rpmdb_printlog > ../../bin/db_printlog > rpm.x86_64: W: dangling-relative-symlink /usr/lib/rpm/rpmdb_verify > ../../bin/db_verify > rpm.x86_64: W: dangling-relative-symlink /usr/lib/rpm/rpmdb_load > ../../bin/db_load > rpm.x86_64: W: dangling-relative-symlink /usr/lib/rpm/rpmdb_svc > ../../bin/berkeley_db_svc > > Build system problem? Anyone seeing this too? From the spec: # plant links to db utils as rpmdb_foo so existing documantion is usable This is done on purpose, and the links aren't dangling when dependencies are installed (rpm main package requires db4-utils) > > rpm.x86_64: W: non-standard-uid /var/lib/rpm/Group rpm > rpm.x86_64: W: non-standard-gid /var/lib/rpm/Group rpm > rpm.x86_64: W: non-standard-uid /var/lib/rpm/Basenames rpm > rpm.x86_64: W: non-standard-gid /var/lib/rpm/Basenames rpm > rpm.x86_64: W: non-standard-uid /var/lib/rpm/Requireversion rpm > rpm.x86_64: W: non-standard-gid /var/lib/rpm/Requireversion rpm > rpm.x86_64: W: non-standard-uid /var/lib/rpm/Providename rpm > rpm.x86_64: W: non-standard-gid /var/lib/rpm/Providename rpm > rpm.x86_64: W: non-standard-uid /var/lib/rpm/__db.007 rpm > rpm.x86_64: W: non-standard-gid /var/lib/rpm/__db.007 rpm > rpm.x86_64: W: non-standard-uid /var/lib/rpm/Pubkeys rpm > rpm.x86_64: W: non-standard-gid /var/lib/rpm/Pubkeys rpm > rpm.x86_64: W: non-standard-uid /var/lib/rpm/__db.003 rpm > rpm.x86_64: W: non-standard-gid /var/lib/rpm/__db.003 rpm > rpm.x86_64: W: non-standard-uid /var/lib/rpm/__db.009 rpm > rpm.x86_64: W: non-standard-gid /var/lib/rpm/__db.009 rpm > rpm.x86_64: W: non-standard-uid /var/lib/rpm/Conflictname rpm > rpm.x86_64: W: non-standard-gid /var/lib/rpm/Conflictname rpm > rpm.x86_64: W: non-standard-uid /var/lib/rpm/Provideversion rpm > rpm.x86_64: W: non-standard-gid /var/lib/rpm/Provideversion rpm > rpm.x86_64: W: non-standard-uid /var/lib/rpm/Triggername rpm > rpm.x86_64: W: non-standard-gid /var/lib/rpm/Triggername rpm > rpm.x86_64: W: non-standard-uid /var/lib/rpm/Filedigests rpm > rpm.x86_64: W: non-standard-gid /var/lib/rpm/Filedigests rpm > rpm.x86_64: W: non-standard-uid /var/lib/rpm/Dirnames rpm > rpm.x86_64: W: non-standard-gid /var/lib/rpm/Dirnames rpm > rpm.x86_64: W: non-standard-uid /var/lib/rpm/__db.004 rpm > rpm.x86_64: W: non-standard-gid /var/lib/rpm/__db.004 rpm > rpm.x86_64: W: non-standard-uid /var/lib/rpm/__db.005 rpm > rpm.x86_64: W: non-standard-gid /var/lib/rpm/__db.005 rpm > rpm.x86_64: W: non-standard-uid /var/lib/rpm/__db.001 rpm > rpm.x86_64: W: non-standard-gid /var/lib/rpm/__db.001 rpm > rpm.x86_64: W: non-standard-uid /var/lib/rpm/__db.002 rpm > rpm.x86_64: W: non-standard-gid /var/lib/rpm/__db.002 rpm > rpm.x86_64: W: non-standard-uid /var/lib/rpm/Name rpm > rpm.x86_64: W: non-standard-gid /var/lib/rpm/Name rpm > rpm.x86_64: W: non-standard-uid /var/lib/rpm/__db.008 rpm > rpm.x86_64: W: non-standard-gid /var/lib/rpm/__db.008 rpm > rpm.x86_64: W: non-standard-uid /var/lib/rpm/Installtid rpm > rpm.x86_64: W: non-standard-gid /var/lib/rpm/Installtid rpm > rpm.x86_64: W: non-standard-uid /var/lib/rpm/Requirename rpm > rpm.x86_64: W: non-standard-gid /var/lib/rpm/Requirename rpm > rpm.x86_64: W: non-standard-uid /var/lib/rpm/Sigmd5 rpm > rpm.x86_64: W: non-standard-gid /var/lib/rpm/Sigmd5 rpm > rpm.x86_64: W: non-standard-uid /var/lib/rpm/Sha1header rpm > rpm.x86_64: W: non-standard-gid /var/lib/rpm/Sha1header rpm > rpm.x86_64: W: non-standard-uid /var/lib/rpm/Packages rpm > rpm.x86_64: W: non-standard-gid /var/lib/rpm/Packages rpm > rpm.x86_64: W: non-standard-uid /var/lib/rpm/__db.006 rpm > rpm.x86_64: W: non-standard-gid /var/lib/rpm/__db.006 rpm > > Discussed already. Yeah, but this shouldn't have been an issue anymore. The files get installed as root:root since quite a while, but there's a leftover "%attr(0644, rpm, rpm)" in the spec. Will fix. > rpm.x86_64: W: dangerous-command-in-%posttrans rm > > Life's dangerous. The rm is necessary for now. > rpm-build.x86_64: E: non-executable-script /usr/lib/rpm/perldeps.pl 0644 > > Investigate please. Explained in the spec: # avoid dragging in tonne of perl libs for an unused script chmod 0644 $RPM_BUILD_ROOT/%{rpmhome}/perldeps.pl > rpm-libs.x86_64: W: no-documentation > rpm-python.x86_64: W: no-documentation > > Upstream problem :).
(In reply to comment #21) > > rpm.x86_64: W: only-non-binary-in-usr-lib > > > > "There are only non binary files in /usr/lib so they should be in /usr/share." > > > > Huh, what? > > Most of /usr/lib/rpm/ contents would be more appropriate for /usr/share/ but > changing that is not so simple, lots of things expect rpm scripts and stuff to > live in the hardwired /usr/lib/rpm directory. This is not going to change > anytime soon. What about putting everything in /usr/share and doing a symlink to /usr/lib?
No, it's not at all that simple. Some of the non-binaries in /usr/lib/rpm are architecture specific configuration files and putting them to /usr/share would be just plain wrong and break things if you actually attempted to share the directory between say ppc and i386. Also rpmbuild puts some actual binaries (like debugedit) into the same directory too, which rpmlint doesn't know as it looks at things a sub-package at a time.
Mass reassigning all merge reviews to their component. For more details, see this FESCO ticket: https://fedorahosted.org/fesco/ticket/1269 If you don't know what merge reviews are about, please see: https://fedoraproject.org/wiki/Merge_Reviews How to handle this bug is left to the discretion of the package maintainer.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
It's almost tempting to wait till January 2017 to get to the 10th anniversary but maybe not. Rpm got plenty of reviewing + cleaning up back then, but if it hasn't gotten officially blessed in 9+ years its not going to happen now either.