At 02:12 16/02/2005, Jani Taskinen wrote:
On Tue, 15 Feb 2005, Zeev Suraski wrote:
At 23:32 15/02/2005, Andi Gutmans wrote:
I still think we should reconsider bundling libxml2 and solve this issue. XML is a center piece of PHP 5 and will be more and more used by extensions as well as developers. I think the benefit far outweighs the downside of bundling.
I know some disagree because of size but I don't see this as an issue. I think giving PHP users a better experience is very beneficial.
Andi beat me to it, but I very much think in the same way. If we kept a .tar.gz in CVS of the 'blessed' libxml2 version, that would become a part of the release tarball during makedist, it would have solved this dependency issue once and for all, and ensure that a given version of PHP behaves in the same way (at least as far XML is concerned) everywhere.
Can you explain this a bit more? Like what kind of 'part' will it become?
Is it just copied there in some directory? How is it configured for compile?
etc.
Inside the php-*.tar.gz packages, it would be very much like sqlite or PCRE that we bundle today, except it's obviously a bit bigger and more complex. We'd have to improve the build process to call configure for this library as a part of the standard configure process.
Considering maintenance, which was one of the big downsides of bundling a library (like PCRE/sqlite), instead of replicating the library in our CVS at the file level, we'd put it as a closed .tar.gz package, and update makedist to fetch it and open it into ext/libxml2 or whatever when it creates packages. That would mean that:
1. Developers (those who checkout the source tree) would have to open it on their own, or have PHP use their system libxml2's.
2. Upgrading the version of bundled libxml2 would basically just mean dropping a new .tar.gz of the new libxml2 version in our CVS, and makedist will do the rest.
This sounds like an extremely bad idea to me. We really need to try to avoid rolling large things into PHP like this. We end up inheriting security fixes and platform specific fixes from these things which could force us into making releases for no reason other than to fix a memory leak or security problem on some weird platform in code we have nothing to do with. And worse, unless the admin is on the ball, he may not even realize a php update is necessary. He sees a security problem in libxml2, updates it and his box still gets hacked because he didn't realize PHP brought its own to the party.
I don't see a huge drawback forcing a dependency on 2.6.x for PHP-5.1. We are still many months away from a production 5.1 release and most distributions are already on that release.
-Rasmus
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
