SRPM URL: http://fedora.biggerontheinside.net/review/perl-Devel-GlobalDestruction-0.02-1.fc9.src.rpm SPEC URL: http://fedora.biggerontheinside.net/review/perl-Devel-GlobalDestruction.spec Description: Perl's global destruction is a little tricky to deal with WRT finalizers because its not ordered and objects can sometimes disappear. Writing defensive destructors is hard and annoying, and usually if global destruction is happenning you only need the destructors that free up non process local resources to actually execute. For these constructors you can avoid the mess by simply bailing out if global destruction is in effect.
This package is a new requirement of Class::MOP. Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=905263
While the %description seems to make sense, Summary: is, well, not terribly helpful. Is anyone supposed to know what PL_dirty is? Could we at least use what upstream has: Expose PL_dirty, the flag which marks global destruction or maybe just Expose the flag which marks global destruction which, while still not completely comprehensible to most folks, is at least understandable by most moderately experienced Perl programmers. Anyway, full review forthcoming.
I had hoped to get that done before leaving work, but.... rpmlint says: perl-Devel-GlobalDestruction-debuginfo.x86_64: E: description-line-too-long This package provides debug information for package perl-Devel-GlobalDestruction. which indeed is long, but not really under your control. Really, the only issue I see is the summary, which I trust you'll fix up to something comprehensible before you check in. * source files match upstream: 1c6665a98a7ee12d2e0ca926b800561f8ff4ea36daf487c02030a12f7a2b959c Devel-GlobalDestruction-0.02.tar.gz * package meets naming and versioning guidelines. * specfile is properly named, is cleanly written and uses macros consistently. X summary is seriously cryptic. * description is OK. * dist tag is present. * build root is OK. * license field matches the actual license. * license is open source-compatible. * license text not included upstream. * latest version is being packaged. * BuildRequires are proper. * compiler flags are appropriate. * %clean is present. * package builds in mock (rawhide, x86_64). * package installs properly. * debuginfo package looks complete. * rpmlint has acceptable complaints. * final provides and requires are sane: GlobalDestruction.so()(64bit) perl(Devel::GlobalDestruction) = 0.02 perl-Devel-GlobalDestruction = 0.02-1.fc10 perl-Devel-GlobalDestruction(x86-64) = 0.02-1.fc10 = perl(:MODULE_COMPAT_5.10.0) perl(Sub::Exporter) perl(strict) perl(vars) perl(warnings) * %check is present and all tests pass: All tests successful. Files=1, Tests=4, 0 wallclock secs ( 0.01 usr 0.01 sys + 0.01 cusr 0.00 csys = 0.03 CPU) * no shared libraries are added to the regular linker search paths. * owns the directories it creates. * doesn't own any directories it shouldn't. * no duplicates in %files. * file permissions are appropriate. * no generically named files * code, not content. * documentation is small, so no -doc subpackage is necessary. * %docs are not necessary for the proper functioning of the package. * no headers. * no pkgconfig files. * no static libraries. * no libtool .la files. APPROVED The package review process needs reviewers! If you haven't done any package reviews recently, please consider doing one.
New Package CVS Request ======================= Package Name: perl-MooseX-StrictConstructor Short Description: Make your object constructors blow up on unknown attributes Owners: cweyl Branches: F-8, F-9, devel InitialCC: perl-sig
cvs done.
Oops. This looks like the request for bug 468799. Can you add another one here for this request and reset the flag?
Man, I hate it when I do that.
New Package CVS Request ======================= Package Name: perl-Devel-GlobalDestruction Short Description: Expose PL_dirty Owners: cweyl Branches: F-8 F-9 devel InitialCC: perl-sig
CVS Done
Package Change Request ====================== Package Name: perl-Devel-GlobalDestruction New Branches: EL-6 Owners: tremble cweyl has previously expressed that he is happy for others to request EPEL branches
CVS done (by process-cvs-requests.py).