Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Bundling libxml2 »

Bundling libxml2

php.internals

Adam Maccabee Trachtenberg

22 years ago
Did we ever come to a conclusion whether we're going to provide a version of PHP 5 that bundles libxml2? Now that we're in RC, I think we should aim to produce packages that are as identical to the final release as possible, so we don't end up with any unexpected surprises later on in the process. PHP 5 enables XML by default and we require a minimum version of libxml2 2.5.10. I know many systems already have a copy of libxml2, but I bet a lot of machines aren't running something that recent. (Like Mac OS X 10.3, for instance.) This could lead to a lot of calls to --disable-xml. -adam
-- adam@trachtenberg.com author of o'reilly's php cookbook avoid the holiday rush, buy your copy today!

Andi Gutmans

22 years ago
We'd need to have someone who'll maintain this by probably having a stable libXML2 tarball someplace in our CVS, and then change makedist to create the two packages (one with and one without libXML2). This should make everyone happy as long as it's properly maintained. Andi At 01:29 PM 4/2/2004 -0500, Adam Maccabee Trachtenberg wrote:

Ilia A.

22 years ago
On April 3, 2004 12:05 pm, Andi Gutmans wrote:
> We'd need to have someone who'll maintain this by probably having a stable > libXML2 tarball someplace in our CVS, and then change makedist to create > the two packages (one with and one without libXML2). This should make > everyone happy as long as it's properly maintained.
While I am not entirely opposed to the idea of bundling libxml2 if XML extensions that are dependant on it are enabled by default there is 1 problem with this approach. Given our history with bundled libraries (gd, expat, sqlite, etc...) we always tend to lag (often quite a bit) behind the official stable release even if we do sync the libraries relatively frequently the release cycle of the libraries themselves is usually much more frequent then that of PHP. Libxml2 in particular seems to have an extremely active release cycle. Another problem is that bundling of a library prevents an easy upgrade of said library by simply recompiling it, instead entire PHP must be rebuilt. Ilia

Adam Maccabee Trachtenberg

22 years ago
On Sat, 3 Apr 2004, Ilia Alshanetsky wrote:
> Given our history with bundled libraries (gd, expat, sqlite, etc...) > we always tend to lag (often quite a bit) behind the official stable > release even if we do sync the libraries relatively frequently the > release cycle of the libraries themselves is usually much more > frequent then that of PHP. Libxml2 in particular seems to have an > extremely active release cycle.
Libxml2 seems flush it's CVS about once a month with a new release whether there's anything earth shattering or not. Usually they contain mostly bug fixes and implementations of more obscure parts of XML specs. While it'd be nice to keep up with it, I don't think it'd be horrible if PHP is a sub point or two behind the latest release. (Although libxml2 does have extensive regression tests, so I rarely hear of bugs breaking in sub point releases.)
> Another problem is that bundling of a library prevents an easy > upgrade of said library by simply recompiling it, instead entire PHP > must be rebuilt.
I see this as an option for people who aren't interested in maintaining libxml2 as a library. (Or, really, libaries in general.) There are lots of libxml2 binaries, RPMs, etc. available from the site, so it's not like it's *that* difficult to install libxml2: http://xmlsoft.org/downloads.html This is for people who can't be bothered or can't learn. -adam
-- adam@trachtenberg.com author of o'reilly's php cookbook avoid the holiday rush, buy your copy today!

Andi Gutmans

22 years ago
At 12:37 PM 4/3/2004 -0500, Ilia Alshanetsky wrote:
>On April 3, 2004 12:05 pm, Andi Gutmans wrote: > > We'd need to have someone who'll maintain this by probably having a stable > > libXML2 tarball someplace in our CVS, and then change makedist to create > > the two packages (one with and one without libXML2). This should make > > everyone happy as long as it's properly maintained. > >While I am not entirely opposed to the idea of bundling libxml2 if XML >extensions that are dependant on it are enabled by default there is 1 problem >with this approach. Given our history with bundled libraries (gd, expat, >sqlite, etc...) we always tend to lag (often quite a bit) behind the official >stable release even if we do sync the libraries relatively frequently the >release cycle of the libraries themselves is usually much more frequent then >that of PHP. Libxml2 in particular seems to have an extremely active release >cycle. Another problem is that bundling of a library prevents an easy upgrade >of said library by simply recompiling it, instead entire PHP must be rebuilt.
Many users (including me) don't always want to use the latest and greatest but want to use something which they know is stable. They'd probably be happy to upgrade PHP and libXML2 in one stable step. Personally I think that as long as the lag isn't too big it's fine and often has its advantages. One of the biggest is that ISPs usually won't turn off default options so they'd automatically have GD, SQlite and XML which is pretty useful. In any case, this is why we would have two tarballs. One for users who want to get the whole bundle and don't want to have to mess with installing the correct version of libXML2, and one package for users like you who prefer being able to upgrade libXML2 without touching PHP. Andi

Wez Furlong

22 years ago
I'll avoid the actual issue here, and just say that keeping tarballs in our CVS is something to avoid (we can keep them elsewhere and stick them in our distro if/when appropriate). --Wez.

Andi Gutmans

22 years ago
It doesn't have to be in the main CVS but it should be in some CVS so that we can do the necessary tag and know which version went into which PHP version. It's much cleaner than taking whatever version is placed in some odd dir on snaps. Andi At 06:44 PM 4/3/2004 +0100, Wez Furlong wrote: