On Sun, 2007-03-11 at 17:44 +1100, Paul TBBle Hampson wrote: > I'm suggesting either. I'm happy to maintain the package seperately, but > I intend to go through the differences between the versions and confirm > that they are compatible, and steal anything good from the php-bundled > version, so in effect I'd be doing both. I'd also have to track upstream > PHP in case they add anything else to the library in the future. So > maybe a PHP package team member might want to be a co-maintainer...
okay, perhaps we can revisit this after you're done. if you decide to use the upstream version we can see how hard it is to build php against that instead of the bundled code. if you decide you want to use the php-bundled version, then we should probably just generate it from the php5 source package directly. i don't use this extension myself, so in any event it would be wise to find someone who does so we can test that it still works :) > A quick poke around the Internet suggested that the only patches being > made by other distros to xmlrpc-epi are for gcc4, 64-bit and expat, but > I haven't looked at the PHP-bundled version's changes yet, apart from > verifying that the .h files match semanticly. did you check that visually, or did you use a utility like icheck? > Hmm, I'd better check this now, all the files in the libxmlrpc directory > carry the same copyright headers as the upstream xmlrpc-epi distribution > (BSD-like), does the PHP license override them and prevent debundling? > I'd like to keep the distinct package under its upstream license if > possible, as it's very very permissive, and the seconde-life client is > GPLd. if the files carry a copyright header i think that they override whatever the default PHP license might say, so i don't think it'd be a problem. sean
signature.asc
Description: This is a digitally signed message part