[Bug 553852] Review Request: pki-tps - The Dogtag PKI System Token Processing System

[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.


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

Chris Weyl <cweyl at alumni.drew.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cweyl at alumni.drew.edu

--- Comment #6 from Chris Weyl <cweyl at alumni.drew.edu> 2010-01-29 11:46:17 EST ---
A couple thoughts here, bearing in mind that it's been a while since I've
reviewed a hardcore non-perl package, so I'm liable to miss something :)  In
arch-specific dir/paths referenced below I'll be using the 64-bit variants, as
that's the machine I'm working on right now.

* In %build, make is called w/o options, not as "make %{?_smp_mflags}".  Any
reason we can't include this?  (e.g. "build breaks when run in parallel")

* It looks like you're installing some sort of web-app as well as apache
modules, but there don't appear to be any config files installed where apache
can find them.

* Given that this is a binary (that is, arch-specific) package, disabling auto
req/provides is not a good idea, as shlib / perl requires (at the least) need
to be picked up and honored.  You're installing shlibs in a system path
(/usr/lib64) and a private path (/usr/lib64/httpd/modules).  AutoReq/prov off
in this situation is not permitted.

* You're also packaging a bunch of perl pakcages _outside_ perl's standard
library path (aka @INC).  Perl provides coming from directories outside @INC
need to be filtered out, one cannot simply "use" them w/o specifying the path. 
Requires coming from directories outside of @INC _are_ valid unless they're
private reqs that are part of that same package (e.g. perl(Parse::RecDescent)
is a valid req of this package, but perl(PKI::TPS::CAInfoPanel) is not.)

Essentially: perl(PKI*) needs to be filtered from both requires and provides,
perl(*::cfg.pl) as well.

* And speaking of perl(*::cfg.pl) -- this must be flitered, in any form.  This
is not a valid system-wide dependency that can be managed by rpm: no package
will ever provide it.

* You're stripping symbols out of shlibs and binaries manually, rather than
letting the debuginfo package generation process handle it.  Is the automatic
process inadequate in some way?  If not, why not let the automatic process do
it?

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