Bug 198023

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.

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

(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 :)

+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!

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.

(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".

(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"?