[Bug 165265] Review Request: libnjb

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: libnjb


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165265


bugs.michael at gmx.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugs.michael at gmx.net




------- Additional Comments From bugs.michael at gmx.net  2005-08-09 08:33 EST -------
[Issue with FE-NEW has been fixed.]

[...]

The src.rpm libnjb-2.2.1-4.src.rpm didn't build here.
Adding "Buildrequires: doxygen" fixed it.

RPM build errors:
    File not found:
/home/qa/tmp/rpm/tmp/libnjb-2.2.1-4-root-qa/usr/share/doc/libnjb-2.2.1
    File not found:
/home/qa/tmp/rpm/tmp/libnjb-2.2.1-4-root-qa/usr/share/doc/libnjb-2.2.1/html
    File not found by glob:
/home/qa/tmp/rpm/tmp/libnjb-2.2.1-4-root-qa/usr/share/doc/libnjb-2.2.1/html/*

[...]

Some comments in the matter of reviewing: I agree with Ralf that the
conditional sections in the spec file introduce questionable things,
which make it somewhat tiresome and error-prone to review such an rpm.
Overuse of macro definitions or redefinitions of macros is another
source of mistakes.

Now, let me point out that only few reviewers would care much about
spec file formatting and optional switches (like --with/--without) or
even conditional sections. The packager is supposed to maintain his
package, not the reviewer. However, as soon as there is enough reason
to believe that a spec file is not straight-forward enough to build
correctly, and if it looks as if the packager will rewrite it
completely for the next update, a reviewer would approve it only
reluctantly. Better keep spec files short and to the point and
hence readable. You just want to package the software reliably, not
turn a spec file into a bloated piece of confusing code, which likely
has introduces increased maintenance requirements.

For instance, the following things are clearly wrong:

> Prefix:         %{_prefix}

Setting the "Prefix:" tag like this marks the package as being
relocatable. It can be proven easily that these packages are _not_
relocatable. Take a look at the contents of e.g. the pkgconfig
file. It contains hardcoded /usr paths. Argueing that the other
files of packages could be relocated nevertheless, would be possible,
but would not fix the package.

> $ rpmlint libnjb-devel-2.2.1-4.i386.rpm 
> E: libnjb-devel standard-dir-owned-by-package /usr/include
> E: libnjb-devel standard-dir-owned-by-package /usr/lib

Both directories (and the corresponding definitions of ownership
and access permissions) belong into the filesystem package only.

> Docdir:		%{prefix}/share/doc

%_docdir (and %_defaultdocdir) is predefined as /usr/share/doc
which is the same as %{_datadir}/doc

> %files
> %defattr(-, root, root)
> %dir %{_libdir}

This %dir statement is the source of the rpmlint error for one
of the directories, which must not be included in your package.
%_includedir as well as /etc/hotplug and /etc/hotplug/usb also
do not belong into your packages.


Other things:

> Source:		%{name}-%{version}.tar.gz

Sourceforge.net URLs of the form

http://download.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
http://dl.sf.net/%{name}/%{name}-%{version}.tar.gz

give direct access to a download server mirror. Just a hint.

> %package examples
> Summary:        Example programs for libnjb
> Group:          System Environment/Libraries

Strange group for example binaries. Minor issue though.

> # Remove static library remnant
> rm -f $RPM_BUILD_ROOT%{_libdir}/libnjb.la

It's a libtool archive, not a "static library remnant".

> mkdir -p $RPM_BUILD_ROOT/etc/hotplug/usb

/etc is %{_sysconfdir} for those who think it may change ever.

> %post
> /sbin/ldconfig
> 
> %postun
> /sbin/ldconfig

Better:

%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig

That will make /sbin/ldconfig the scriptlet command interpreter
and create automatic dependencies on /sbin/ldconfig. Your version
would include a shell script, which runs /sbin/ldconfig.

-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.