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
signature.asc
Description: Digital signature
