php bundles a copy of modified copy of libzip - it has at least one API addition relative to upstream libzip 0.9.3; php upstream have stated their intent to not support a system libzip: http://bugs.php.net/bug.php?id=39388
Can we have an exception to continue bundling a modified libzip with php?
From the minimal information given here, I'm guessing we'd probably vote no on this. There doesn't seem to be any reason that we shouldn't be getting the additional fixes into our libzip package in Fedora. The additional features would need more information about the conversation that was had with upstream libzip and why upstream did not take them (or if upstream did take them into their cvs version, why we don't carry the additions in our Fedora package). You can use the information in this section of the guidelines to provide additional information that may build a better case for bundling:
When you're ready for the Packaging Committee to take a look at this (you've either added information from the standard questions or decided to proceed without more information), set the Meeting keyword and we'll take a look and vote on it.
php bundles a libzip which is a fork of libzip 0.9.0
There are various changes which have never been merged by upstream.
* new feature (ZIP_OVERWRITE option to open)
* behavior change with stream end during read and CRC
* behavior change when search for a file in an archive (error cast is disabled)
* allow empty dir
Changes in 0.9.1, 0.9.2, 0.9.3 were never merged in php
libzip 0.10 is now available, this a major version with lot of changes
Porting php changes to system libzip will be a big work (I have spent some time on it, without real success), and this will introduce some changes, all the consumer applications probably don't handle.
security fixes are managed by php team which could be consider as upstream for this library.
PHP team strongly refuse to allow the build against the system library. p.e. : http://pecl.php.net/bugs/bug.php?id=9292
In looking at the changes that PHP made, remi is not kidding about the behavior changes, they're easily API incompatible with libzip 0.9.3, much less 0.10. I can't imagine upstream is interested in these changes, but I would want to try to have PHP open a dialog with libzip.
It is worth pointing out here that the Fedora package does not have zip support enabled (at least in rawhide), so it is avoiding this issue at the moment.
However, at a glance, it looks like very few packages (less than 10) actually use libzip, so it probably isn't impossible to carry that PHP patch, even if upstream libzip doesn't pick it up immediately.
I've sent a patch with the necessary changes from PHP's bundled copy (against 0.10), ignoring the changes that I don't think are needed, to the libzip upstream for consideration.
I also made a patch for PHP to support system libzip (note: it won't work without applying the PHP changes to that library), and it seems to work, but I didn't really test the zip support, as I'm not a PHP programmer.
Updated https://bugs.php.net/bug.php?id=39388 with the patches.
I think this one could be closed as PHP 5.4 in Fedora 17 now use system libzip.
Indeed, and Provides, Requires are good. Thanks!
to comment on this ticket.
Copyright © 2014-2017 Red Hat
3.10.1 — Documentation