Bug 226377

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.