[pkg-php-pear] Bug#781414: Embedded code copies

[David Prévot]

Hi Gunnar, and PHP PEAR Maintainers,

On Wed, Apr 01, 2015 at 10:52:54PM -0600, Gunnar Wolf wrote:

> Sorry for the lateness - I'm currently devoid of free time, and my
> package maintainance status has suffered :(

It’s not even been a week since that bug was filed, so no need to
apologize (and yay, double happy event may drag one into other
activities, cheers! ;).

> - For php-seclib, after a quick diff, the version I currently have in
>   Sid (0.3.8-1) seems clearly newer [...] In your experience, how
>   incompatible would you expect a new version to be? Do you think I
>   could just drop in the new one and not suffer too much?

I’ve introduced php-seclib in the archive to get rid of the embedded
code copy from ownCloud, and must admit I’ve never notice any BC break:
I’m happy to track the latest php-seclib upstream release for almost two
years now, it seems to behave correctly ;).

> - As for php-htmlpurifier, it seems we are lucky as both packages
>   carry 4.6.0.

That’s a relief (#764885 would have applied otherwise).

>   However, the one in Collabtive is a standalone file,
>   stating in its header:
> 
>  * This file was auto-generated by generate-includes.php and includes all of
>  * the core files required by HTML Purifier. Use this if performance is a
>  * primary concern and you are using an opcode cache. PLEASE DO NOT EDIT THIS
>  * FILE, changes will be overwritten the next time the script is run.
> 
> So... Do you know what'd be the best way for this file to be replaced
> (or generated) from the package we are shipping?

Simply requiring 'HTMLPurifier.autoload.php' (or
'HTMLPurifier.includes.php', or 'HTMLPurifier.safe-includes.php', or…)
instead of the standalone file should do the trick.

Feel free to bug php-htmlpurifier if you really want it to provide a
big standalone file, but I’m not sure that’s necessary (nor a good
idea at first sight). Please, note I only team-uploaded this package
once, so I may not be the best person to provide more insight.

> > It looks like most existing PHP classes used as dependencies are
> > currently symlinked. You may consider including them from where they
> > belong instead.
> 
> I prefered symlinking as it requires less patching of the upstream
> code. But, of course, if the PHP packaging group's best practices are
> to patch, I will do so. Just please confirm!

I’m a bit new in the PHP PEAR Maintainers team, other members may
provide more insight here. My short experience with ownCloud packaging
is that previous maintainers did it that way, and it looks a lot less
hackish. E.g., if a file is added in an updated PHP class, as long as
that file is not (yet) symlinked from the webapp using it, you may shoot
yourself in the foot if this file is called from an existing one…

Regards

David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-pear/attachments/20150402/2206ec8a/attachment.sig>