Bug 198023 - Review Request: perl-POE-Component-Logger
Review Request: perl-POE-Component-Logger
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Tibbitts
Fedora Package Reviews List
:
Depends On: 198021
Blocks: FE-ACCEPT
  Show dependency treegraph
 
Reported: 2006-07-07 23:58 EDT by Chris Weyl
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-08 20:59:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chris Weyl 2006-07-07 23:58:56 EDT
Spec URL: http://home.comcast.net/~ckweyl/perl-POE-Component-Logger.spec
SRPM URL:
http://home.comcast.net/~ckweyl/perl-POE-Component-Logger-1.00-0.fc5.src.rpm

Description: 
POE::Component::Logger provides a simple logging component that uses
Log::Dispatch::Config to drive it, allowing you to log to multiple places at
once (e.g. to STDERR and Syslog at the same time) and also to flexibly define
your logger's output.

It is very simple to use, because it creates a Logger::log method (yes, this
is namespace corruption, so shoot me). If you don't like this, feel free to
post directly to your logger as follows:

  $kernel->post('logger', 'log', "An error occurred: $!");

All logging is done in the background, so don't expect immediate output -
the output will only occur after control goes back to the kernel so it can
process the next event.
Comment 1 Ralf Corsepius 2006-07-08 00:46:56 EDT
package is noarch

=>   OPTIMIZE="%{optflags}"
is unused/superfluous.

=>  This find also is very likely unnecessary:
find %{buildroot} -type f -name '*.bs' -a -size 0 -exec rm -f {} ';'

Chris, Jason, this is a systematic bug in most (all) of Chris's perl packages.
Comment 2 Jason Tibbitts 2006-07-08 01:09:37 EDT
I was finishing up the review, so I'll include it below.

The lines are indeed superfluous and simply caused by following the specfile
template.  I don't see them as blockers, or honestly even as bugs, although I'll
try to note them in the future.

* source files match upstream:
   b36cfad2d2d446103cbcf671270681ff  POE-Component-Logger-1.00.tar.gz
* package meets naming and packaging guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* dist tag is present.
* build root is correct.
* license field matches the actual license.
* license is open source-compatible.  License text not included upstream.
* latest version is being packaged.
O BuildRequires are proper (BR: perl is not required)
* %clean is present.
* package builds in mock (development, x86_64, approved dependencies added to
local repo)
* rpmlint is silent.
* noarch package, so no debuginfo.
* final provides and requires are sane:
   perl(POE::Component::Logger) = 1.00
   perl-POE-Component-Logger = 1.00-0.fc6
  =
   perl(:MODULE_COMPAT_5.8.8)
   perl(Log::Dispatch::Config)
   perl(POE)
   perl(strict)
   perl(vars)
* %check is present and all tests (all one of them) pass:
   All tests successful.
   Files=1, Tests=1,  0 wallclock secs ( 0.07 cusr +  0.03 csys =  0.10 CPU)
* no shared libraries are present.
* package is not relocatable.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* no scriptlets present.
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no libtool .la droppings.
* not a GUI app.

APPROVED
Comment 3 Chris Weyl 2006-07-08 20:19:53 EDT
(In reply to comment #1)
> package is noarch
> 
> =>   OPTIMIZE="%{optflags}"
> is unused/superfluous.
> 
> =>  This find also is very likely unnecessary:
> find %{buildroot} -type f -name '*.bs' -a -size 0 -exec rm -f {} ';'
> 
> Chris, Jason, this is a systematic bug in most (all) of Chris's perl packages.

How is this a "bug"?  It's part of the standard perl specfile template, doesn't
conflict with any of the packaging guidelines, and it certainly isn't doing any
harm.  Is it worth 5-10 min of my time to to make sure that these lines are
indeed not needed, and then another 5-10min for the reviewer to also 1) notice
the deviation from the template, and 2) ensure that the packager's determination
that the lines are superfluous and can be dropped is correct?

If this is a "bug", then let's get it before the packaging committee and have
the guidelines for perl packages changed to explicitly require excising those
lines.  Otherwise, let's call it "packager's preference/style"; and as they say
in perl-land, TMTOWTDI :)
Comment 4 Chris Weyl 2006-07-08 20:59:16 EDT
+Import to CVS
+Add to owners.list
+Bump release, build for devel
+devel build succeeds
+Request branching (FC-4, FC-5)
+Close bug

Thanks for the review!
Comment 5 Jason Tibbitts 2006-07-08 21:02:30 EDT
For noarch packages, passing OPTIMIZE is pointless as the compiler isn't called,
and perl will never create .bs files.  Ralf says including them is a bug, which
is rather ludicrous; I just call them cruft that doesn't need to be there but
which doesn't hurt.  If you were inventing random needless things and sticking
them in the spec then I would see an issue, but these are verbatim from the
specfile template and honestly I don't see how you coule expect anyone but an
expert to know that the find line is always needless for a noarch package.

If it were my package, I would remove the cruft because I'd want the spec to be
as simple as possible.  I don't expect and certainly don't require that everyone
else do the same thing; keeping things as close as possible to the template also
has its benefits.
Comment 6 Ralf Corsepius 2006-07-08 23:48:41 EDT
(In reply to comment #3)
> (In reply to comment #1)
> > package is noarch
> > 
> > =>   OPTIMIZE="%{optflags}"
> > is unused/superfluous.
> > 
> > =>  This find also is very likely unnecessary:
> > find %{buildroot} -type f -name '*.bs' -a -size 0 -exec rm -f {} ';'
> > 
> > Chris, Jason, this is a systematic bug in most (all) of Chris's perl packages.
> 
> How is this a "bug"?  It's part of the standard perl specfile template,
@Cris: Start thinking about what you are doing!

> doesn't conflict with any of the packaging guidelines,
If you were around to perl packaging in Fedora a little longer, you'd know that
not using OPTIMIZE and dropping the find had been part of older Fedora perl
templates.

For reasons unknown to me, this somehow has fallen out of the current templates.

> and it certainly isn't doing any harm. 
Perl makefiles are generated on the fly, therefore you never can be sure what
they are doing.

Are you sure the package's author hasn't added a custom VAR named OPTIMIZE? Are
you sure the perl-magic a package uses, suffers from a bug and abused OPTIMIZE? 
=> They are likely not to do any harm, but certainly not "certainly".
Comment 7 Ralf Corsepius 2006-07-09 08:31:11 EDT
(In reply to comment #5)
>  Ralf says including them is a bug, which is rather ludicrous;
Well, cluttering a spec file with superfluous and useless cruft to me is a
specfile bug. May be you would agree to the words "sloppy" or "careless"?


Note You need to log in before you can comment on or make changes to this bug.