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.
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
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 {} ';'
(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.
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
(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.
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.
(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."
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?
Package Change Request ====================== Package Name: perl-POE-Filter-IRCD New Branches: el6 Owners: averi psabata InitialCC: perl-sig
Git done (by process-git-requests).