Red Hat Bugzilla – Bug 226240
Merge Review: perl-Archive-Zip
Last modified: 2011-01-19 04:39:53 EST
Fedora Merge Review: perl-Archive-Zip
Initial Owner: firstname.lastname@example.org
Created attachment 150536 [details]
- Update to 1.18.
- Fix find option order.
- Use fixperms macro instead of our own chmod incantation.
- Remove check macro cruft.
- Update build dependencies.
- Package LICENSE.
- BR unzip, zip for better test coverage.
I don't see where any of that are blockers.
Oh, I forgot to mention that the newer version introduces a build dependency on
File::Which, which is in Extras.
It doesn't appear to be any important bug fixes here. Could we wait on the
version upgrade until after Fedora 7? (Moving a package now after the feature
freeze is a bit of a pain.)
1.18 Wed 25 Oct 2006 - Adam Kennedy
- Changing to a production version for final release
- No other changes of any kind
1.17_05 Tue 19 Sep 2006 - Adam Kennedy
- Seperated the classes from the main file into seperate packages.
- Merged the Zip.pod into the main Zip.pm file.
- Applied default Perl::Tidy to all of the source files, to improve
the readability and maintainability of the files.
- Added license in Makefile.PL
- Added some additional entries to the realclean files
Could you resubmit with a cleaned up spec for the 1.16 version instead?
(In reply to comment #4)
> Could you resubmit with a cleaned up spec for the 1.16 version instead?
I'd rather just see the patch applied whenever it is convenient. It's all minor
cleanup and changes related to the version upgrade.
The patch can't really be applied until after the merge anyway given the new
dependency on File::Which.
It's after the merge... Ignoring the part about updating to the new version,
my patch would still apply (and give better test coverage).
And then this bug could be closed too. :-)
Done - perl-Archive-Zip-1_20-2_fc8
Package Change Request
Package Name: perl-Archive-Zip
New Branch: EL-5
oops, I withdraw the request from comment #8, the package is going to appear in RHEL-5. Thanks.
If/when it will appear in RHEL-5 (that is at least 3 months from now) it should have a newer e-v-r than what EPEL provides and everybody will be happy. Meanwhile we have a bunch of packages in EPEL-5 which cannot be installed due to this package not being available.
This package is in EPEL5, but not in EPEL6. Is there any reason for that?
I would like to see this package in EPEL6, and I am willing to help co-maintain it.
Nevermind, I just saw it's in the RHEL6 Client repository (I was only looking at the Server one).
Sorry for the spam.