Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 198881 - Review Request: perl-POE-Filter-IRCD
Summary: Review Request: perl-POE-Filter-IRCD
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jason Tibbitts
QA Contact: Fedora Package Reviews List
URL:
Whiteboard:
Depends On:
Blocks: FE-ACCEPT 198882
TreeView+ depends on / blocked
 
Reported: 2006-07-14 11:41 UTC by Chris Weyl
Modified: 2013-05-07 12:54 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-07-19 04:46:37 UTC
Type: ---
Embargoed:
gwync: fedora-cvs+


Attachments (Terms of Use)

Description Chris Weyl 2006-07-14 11:41:45 UTC
Spec URL: http://home.comcast.net/~ckweyl/perl-POE-Filter-IRCD.spec
SRPM URL: http://home.comcast.net/~ckweyl/perl-POE-Filter-IRCD-1.7-0.fc5.src.rpm

Description: 
POE::Filter::IRCD provides a convenient way of parsing and creating IRC
protocol lines.

Comment 1 Chris Weyl 2006-07-18 15:30:09 UTC
Updated to add licensing clarification.

Spec URL: http://home.comcast.net/~ckweyl/perl-POE-Filter-IRCD.spec
SRPM URL: http://home.comcast.net/~ckweyl/perl-POE-Filter-IRCD-1.7-0.1.fc5.src.rpm

Comment 2 Ralf Corsepius 2006-07-18 15:45:34 UTC
BuildArch:      noarch

=> These lines are superfluous - Remove them.

%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="%{optflags}"

find %{buildroot} -type f -name '*.bs' -a -size 0 -exec rm -f {} ';'



Comment 3 Ralf Corsepius 2006-07-18 15:47:14 UTC
(In reply to comment #2)
> BuildArch:      noarch
> 
> => These lines are superfluous
Oops, too fast on the send button:

The find line and the OPTIMIZES in the lines cited are superfluous - Remove them.




Comment 4 Jason Tibbitts 2006-07-18 16:09:19 UTC
Ralf, honestly, please stop hammering on the packagers and get the Perl specfile
template changed instead.  Maybe make fedora-newrpmspec call into cpanspec
instead, which will not generate the bits you object to for noarch packages. 
I'm not going to block on anything that's just following the template that we
put in place for them to follow.

Chris, thanks for clarifying the license issue after our discussion on IRC.

Review:
* source files match upstream:
   30ab7c5504eb6d99c7d3da399933efac  POE-Filter-IRCD-1.7.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.
* latest version is being packaged.
O BuildRequires are proper (BR: perl is unnecessary)
O Compiler flags are appropriate (no need to pass them to the makefile of a
noarch package)
* %clean is present.
* package builds in mock (development, x86_64).
* rpmlint is silent.
* noarch package, no debuginfo.
* final provides and requires are sane:
   perl(POE::Filter::IRCD) = 1.7
   perl-POE-Filter-IRCD = 1.7-0.fc6
  =
   perl(:MODULE_COMPAT_5.8.8)
   perl(Carp)
   perl(base)
   perl(strict)
   perl(vars)
   perl(warnings)
* %check is present and all tests pass:
   All tests successful.
   Files=1, Tests=7,  0 wallclock secs ( 0.02 cusr +  0.01 csys =  0.03 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 5 Paul Howarth 2006-07-18 16:15:01 UTC
(In reply to comment #4)
> Ralf, honestly, please stop hammering on the packagers and get the Perl specfile
> template changed instead.

I'm with Ralf on this, as usual. The template is a starting point, and that's
all. It needs customising for each package, which involves adding
package-specific stuff and removing bits that aren't needed. It really isn't an
onerous task to remove the bits that aren't needed and it sets a good example
for other packagers, who often look at existing packages in the repository to
find out out what "best practice" is.

> Maybe make fedora-newrpmspec call into cpanspec
> instead, which will not generate the bits you object to for noarch packages.

That would be nice, but fedora-newrpmspec does not appear to have an interface
for specifying whether a package is noarch or not.
 
> I'm not going to block on anything that's just following the template that we
> put in place for them to follow.

It's a template, not a release-ready spec file.


Comment 6 Jason Tibbitts 2006-07-18 16:40:06 UTC
The point is that none of the issues raised are blockers.  If you want to make
them blockers, float a proposal in the packaging committee.  I might even vote
for it.  But I'm not going to make Chris change all of his specs when:

1) The extra bits aren't harmful.
2) They're in the template we tell people to use.
3) He's stated that he wants to stick close to the template.

Do I wish Chris would eliminate the unneeded bits?  Yes.  Are they blockers for
his package?  Not until the guidelines change to make them blockers.

Comment 7 Ralf Corsepius 2006-07-19 03:10:45 UTC
(In reply to comment #4)
> Ralf, honestly, please stop hammering on the packagers and get the Perl specfile
> template changed instead. 

Jason, honestly, this issue really p***** me off.

I would prefer you to stop blindly approving such sloppily and carelessly
packaged packages and you undermining what had been perl package packaging
practice almost ever since FE exists.

Almost no other packages but Chris submitted/Jason approved perl packages in FE
contain the OPTIMIZE/find *.bs.


(In reply to comment #5)
> It's a template, not a release-ready spec file.
Exactly. People are supposed to customize it.

(In reply to comment #5)
> But I'm not going to make Chris change all of his specs when:
You better should. To me Chris has sufficently demonstrated his resistance to
learning.

> 1) The extra bits aren't harmful.
As I've repeatedly said, you can not be sure about this.

> 2) They're in the template we tell people to use.
It's a template - not a form, nor is a review a government's agency's
bureaucratic act nor a mechanical act.

> Do I wish Chris would eliminate the unneeded bits?  Yes.
Then you should better teach him to do so. You wouldn't use the OPTIMIZE and the
find in non-perl *.specs? Using them in noarch packages are equally "useful."
 


Comment 8 Chris Weyl 2006-07-19 04:46:37 UTC
Ok, I think the rhetoric here is getting a touch out of hand, and making a very
large issue out of a not-so-large one.

Perl modules are fairly "special", in that basically the same specfile can
handle all of them (with package specific description, etc, being adapted, of
course).  They're also special in that there's a LOT of them.

For those two reasons, I try to hew as close to the specfile template as
possible.  --> The closer to the template a perl module spec is the more readily
apparent errors are, especially when there's a _lot_ of them. <--

It's easy to scan a perl spec and almost instinctively know when something is
missing, when as little deviation as necessary is made from it.

Ralf, I do not do this "mindlessly", "without thinking", or "sloppily".  I do
check to ensure the extra lines (w.r.t. OPTIMIZE) doesn't adversely impact the
building of the package. I'm not resistant to learning, and in fact find myself
learning daily and seeking input.  To date I haven't been provided with any
reason why, in my judgement, it would be advantagous to abandon this practice.

If you want, bring this issue before the packaging committee.  If guidelines
come down or new spec templates are issued recommending the dropping of those
lines, I'll comply.  Until then, can we not accept it as a legitimate choice a
packager may make under the guidelines?

Can we continue this discussion off bugzilla -- in any bug -- if we absolutely must?

Comment 9 Andrea Veri 2013-05-07 11:45:30 UTC
Package Change Request
======================
Package Name: perl-POE-Filter-IRCD
New Branches: el6
Owners: averi psabata
InitialCC: perl-sig

Comment 10 Gwyn Ciesla 2013-05-07 12:54:37 UTC
Git done (by process-git-requests).


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