[Bug 435835] Review Request: perl-RPC-XML - Set of classes for core data, message and XML handling

[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: perl-RPC-XML - Set of classes for core data, message and XML handling
Alias: perl-RPC-XML

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


cweyl at alumni.drew.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cweyl at alumni.drew.edu
              Alias|                            |perl-RPC-XML




------- Additional Comments From cweyl at alumni.drew.edu  2008-03-14 15:42 EST -------
A couple thoughts prior to a full-fledged review:

The %perl_vendorarch and %perl_vendorlib macros have been defined by the
system since...  oh, about RHEL3 or so.  They should probably be dropped
unless you're explicitly keeping them in there to better deal with old
systems; in that case they should be conditionalized, however.

Using macros a la %{__rm} is legit, and you use them cleanly and consistently,
but they're still a bit odd in Fedora.  I wouldn't consider it a blocker,
however.  :)

Your buildroot is slightly wonky; Fedora generally uses
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

You have the man pages marked %doc...  AFAIK convention is to not mark these as
such, though I'm not entirely sure convention is correct in this case.

The Apache::RPC::Server/::Status modules pull in mod_perl, which in turn has a
slew of requirements of its own (not the least of which is apache).  I'd break
them out into a subpackage to avoid a rather large potentially unwanted
dependency tree.

Your buildrequires are incomplete:  judging by Makefile.PL there are a couple
more you're going to want to throw in there.  Note also that it's key to start
including core modules such as Test::More if so required.

It's often helpful to kick off a koji scratch build and post the link to the
task results in the bug review (a relatively recent development).  It's also a
good self-sanity check to ensure the package builds as intended.

-- 
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, or are watching someone who is.