Re: [PHP-DEV] bundling libxml2 / bundling locations
On Thu, May 30, 2002 at 02:03:40PM -0700, brad lafountain wrote: We are only talking about a few cvs commands here! We aren't talking about a huge effort. Any effort like this seems like duplicated effort to me. I don't see bad merges a problem here. It's not like I would be applying patches or getting the latest and greates from libxml's cvs. Peridocially someone would just need to update the source files from the 'newest' release. If you're just tracking libxml's tree, why do it at all? I fail to see the benefit here. But as I explained before besides bug fixes and speed increases you wouldn't get much from keeping totally up to date with the bundled libxml. And again.. its not like we are forcing the version on the user nor making it an inconvenionce for them if they already have libxml installed. IMHO, having two ways to accomplish the same thing seems like either duplicated effort or overcomplication. I don't know how much developement other people do but use xml/xml techiologies on a daily basis. I see this is the trend of many developers but I obvisouly cant speak for them. Just because some people do XML development on a daily basis is no reason libxml should be bundled with every one of their favorite technologies. The ability to build outta the box is also what many system admins what to see, maybe not the hacker ones but the ones who just get the job done. I also know alot of managers that will pay for software just cuase it runs outta the box. No needing to depend on other software is installed. That is a poor goal at best, and a disaster at worst. IMO code quality is increased with code modularity. Let libxml do its job and PHP do its own job. I still fail to see what benefit you perceive. There will always be companies willing to buy and sell software like PHP (my employer* sells products that include PHP). I think these companies provide great benefit to their customers. Although I haven't read this entire thread nor heard all sides of the argument, at this point I'm -0.9 to the whole idea. Unless there is a *very* good reason for including 3rd party libraries in PHP, I beleve that should be strongly avoided. -aaron * Email me privately if you don't know who I work for and would like to find out. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
At 07:16 PM 5/30/2002, Stig S. Bakken wrote: On Thu, 2002-05-30 at 18:08, [EMAIL PROTECTED] wrote: On Thu, 30 May 2002, brad lafountain wrote: The 2M size has alot of stuff that we wouldn't need. Im sure we can get it down to under 500K. I still think 500kb is too much for something the most ppl already have installed. Having a too old version installed doesn't help much in this case. :-) If Brad is able to trim down libxml2 to a reasonable size, I'm +1 Same here. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
At 07:08 PM 5/30/2002, [EMAIL PROTECTED] wrote: On Thu, 30 May 2002, brad lafountain wrote: The 2M size has alot of stuff that we wouldn't need. Im sure we can get it down to under 500K. I still think 500kb is too much for something the most ppl already have installed. How do you figure that most people have it installed? Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
At 11:39 PM 5/30/2002, Dan Kalowsky wrote: On Thu, 30 May 2002, brad lafountain wrote: I personally will take responsiblity for bundling and upgrading it. As Rasmus stated earlier the reason the MySQL stuff is bundled is due to an assurance from the MySQL developers to keep it updated. I don't think such an assurance existed to begin with, and whether it existed or not, it definitely wasn't the case in the beginning, and I'm not sure how well it's going now. We bundled it not because of any assurance, but because we decided it was important, and we were fed off the Call to undefined function calls on php-general. I don't see why it's a problem to bundle libxml2 at all. It doesn't have to be in our CVS, we can integrate it into the makedist procedure, provided Brad can automate his trim-down process. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] bundling libxml2 / bundling locations
TONGUE_IN_CHEEKReally what we should do is in the configure process, if --with-dom is specified and not found on the system, we could call wget, untar, ./configure make, etc. It's the same right? Oh, then we depend on wget being installed./TONGUE_IN_CHEEK What is the status quo? If you install perl on a system, it runs out of the box right? Sure, well so does php, except that expat is required to build php, so it's bundled. Now, when you install a perl module, you also have to install the libraries upon which it depends. That's only fair. It's the accepted status quo. Effort would far better be spent creating an extension dependency tree page that links to the libxml page so that if one wants to install an extension, he or she knows exactly where to go to get the libraries that they depend on. No suprises, no gimmicks. Now on Windows or similar systems, where the average user is not used to system administration (witness the number of codered attacks still going around), we can pack all these dependant binary libraries into the installer. I'm not sure who builds the installer, but I know I could make one in no time flat, and would be willing to do so (and even automate a build process if necessary). -1 on the bundling idea. +1 for choice. +1 for binary bundling on Windows. Joseph -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: Friday, May 31, 2002 11:05 AM To: Dan Kalowsky Cc: brad lafountain; PHP Development Mailing list Subject: Re: [PHP-DEV] bundling libxml2 / bundling locations At 11:39 PM 5/30/2002, Dan Kalowsky wrote: On Thu, 30 May 2002, brad lafountain wrote: I personally will take responsiblity for bundling and upgrading it. As Rasmus stated earlier the reason the MySQL stuff is bundled is due to an assurance from the MySQL developers to keep it updated. I don't think such an assurance existed to begin with, and whether it existed or not, it definitely wasn't the case in the beginning, and I'm not sure how well it's going now. We bundled it not because of any assurance, but because we decided it was important, and we were fed off the Call to undefined function calls on php-general. I don't see why it's a problem to bundle libxml2 at all. It doesn't have to be in our CVS, we can integrate it into the makedist procedure, provided Brad can automate his trim-down process. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
On Fri, 31 May 2002, Zeev Suraski wrote: As Rasmus stated earlier the reason the MySQL stuff is bundled is due to an assurance from the MySQL developers to keep it updated. I don't think such an assurance existed to begin with, and whether it existed or not, it definitely wasn't the case in the beginning, and I'm not sure how well it's going now. We bundled it not because of any assurance, but because we decided it was important, and we were fed off the Call to undefined function calls on php-general. I'm basing my stance on a post made earlier in this discussion by Rasmus. I really wasn't around during that decision process, so I can't comment on it further. --- Dan KalowskyThe record shows, I took the blows. http://www.deadmime.org/~dankAnd did it my way. [EMAIL PROTECTED] - My Way, Frank Sinatra [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
On Fri, 31 May 2002, Zeev Suraski wrote: As Rasmus stated earlier the reason the MySQL stuff is bundled is due to an assurance from the MySQL developers to keep it updated. I don't think such an assurance existed to begin with, and whether it existed or not, it definitely wasn't the case in the beginning, and I'm not sure how well it's going now. We bundled it not because of any assurance, but because we decided it was important, and we were fed off the Call to undefined function calls on php-general. I'm basing my stance on a post made earlier in this discussion by Rasmus. I really wasn't around during that decision process, so I can't comment on it further. Well, I guess perhaps Assurance was not the right word, but the decision to bundle it came after a face to face meeting with the main MySQL folks who at that time agreed to maintain it. In this case the libxml2 developers appear to think it is a bad idea for us to bundle it and I would like to understand a bit more why they have this opinion. I really don't like bundling something against the wishes of the authors. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
Now on Windows or similar systems, where the average user is not used to system administration (witness the number of codered attacks still going around), we can pack all these dependant binary libraries into the installer. I'm not sure who builds the installer, but I know I could make one in no time flat, and would be willing to do so (and even automate a build process if necessary). -1 on the bundling idea. +1 for choice. +1 for binary bundling on Windows. FYI the binary version of the lib is bundled in win32 distribution. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
On Wed, 29 May 2002, Alexander Wagner wrote: But take ext/domxml it requires a newerversion of libxml2. I didn't have it installed on my machine when i installed php. If we bundle say a specfic version of libxml2 that domxml depends on, then it won't matter how fast pased the development is, ext/domxml won't use it. We can obvisouly peridocially upgrade the version that is bundled and you can have an override if you want to use a different version that is installed on a system. As xml gets more and more popular i feel that domxml will be more and more popular. I'd make it an optional download, because there are always people like me who have all the libraries already installed with their distro. People with non-deb distros or who are lacking skills with Linux but want to do it anyway would definately benefit from this. I don't think: ./configure make make install ldconfig is that hard to grasp for anybody... [...] Derick --- Did I help you? http://www.jdimedia.nl/derick/link.php?url=giftlist Frequent ranting: http://www.jdimedia.nl/derick/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
On Thu, 30 May 2002, Yasuo Ohgaki wrote: Brad Lafountain wrote: But take ext/domxml it requires a newerversion of libxml2. I didn't have it installed on my machine when i installed php. If we bundle say a specfic version of libxml2 that domxml depends on, then it won't matter how fast pased the development is, ext/domxml won't use it. We can obvisouly peridocially upgrade the version that is bundled and you can have an override if you want to use a different version that is installed on a system. As xml gets more and more popular i feel that domxml will be more and more popular. Build outta the box +1 for libxml2 bundle. This already discussed, isn't this? -1 on this, as libxml2 is quite big, it would increase the PHP source by about 60%: File: php-4.2.1.tar.gz 3298 KB 05/13/2002 09:02:00 PM File: libxml2-2.4.17.tar.gz 1861 KB 03/08/2002 12:00:00 AM And I don't think it would be a good idea to bundle it even if it was small. A project like libxml changes so much with releases every two weeks that it would be a hell to keep upgrading the bundled library in order to have the latest version. Derick --- Did I help you? http://www.jdimedia.nl/derick/link.php?url=giftlist Frequent ranting: http://www.jdimedia.nl/derick/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
On Thu, 30 May 2002, Yasuo Ohgaki wrote: Markus Fischer wrote: On Thu, May 30, 2002 at 09:58:31AM +0900, Yasuo Ohgaki wrote : Markus Fischer wrote: Build outta the box +1 for libxml2 bundle. This already discussed, isn't this? -1 It's very actively developed. What is the reason of shared libraries if we don't use it?! GD is a completely different story. I even think it's not necessary to bundle libmysqlclient because it's really installed everywhere where mysql is available. I undstand libxml2 develpment is very active. That's the one of the reason why I prefer to bundle. For example, I have to build libxml RPM by myself to install PHP 4.3.0, since it requires too new libxml2 :( Just another RPM build, though. So? What is wrong with that?! Just a pain to install :) The libxml project provides their own RPMs, so building them yourself is not really needed. [...] If we go with this paradigm we'ld have to bundle everything with PHP. Typically, administrators of such systems already live with that they have to rebuild and update packages. Not really, we just need to bundle libs that may have conflicts. GD is one, and libxml2 is another. (libxml2 changes too frequently and PHP requires specific version including patch level release. I think we can remove expat bundle now.) PHP doesn't need a patch release of libxml2, 2.4.14 is required in 4.2.1 and 4.3.x. [...] Derick --- Did I help you? http://www.jdimedia.nl/derick/link.php?url=giftlist Frequent ranting: http://www.jdimedia.nl/derick/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
On Wed, 29 May 2002, brad lafountain wrote: My point of view is domxml does require a newish version of libxml2. It't not going to hurt if we bundle that version with php. The configure script can even It does hurt... adding almost 2 MB to a distribution is simply insane IMO. Even people who don't need domxm, or libxml have to download this... [...] Derick --- Did I help you? http://www.jdimedia.nl/derick/link.php?url=giftlist Frequent ranting: http://www.jdimedia.nl/derick/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
On Thu, 30 May 2002, Andi Gutmans wrote: I think that XML is a core technology and giving plugplay access to our users is important. Having bundled the MySQL library made it easier for people to get started with MySQL. Does that mean I think every library should be bundled with PHP? No, I don't. But if libxml2 is a moving target and it's hard to stay in sync then it certainly sounds beneficial to take away this headache from our users. It also means that other XML based extensions could use it by default. Of course it also depends how big it is. If we can strip it down a lot I'd be a +1. If it'd add 1 MB to our .tar.gz I would be against. THe normal source distribution is almost 2 MB... Derick --- Did I help you? http://www.jdimedia.nl/derick/link.php?url=giftlist Frequent ranting: http://www.jdimedia.nl/derick/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
Dan: If we start down this path of bundling external projects, why don't we just bundle every external project PHP supports to make it the easiest? This is just an absurd notion to bundle an actively developed/maintained piece of code. The headaches it will introduce are not worth the minor benefit. I think the solution would be to allow PECL to optionally fetch the libraries an extension depends on, quite like FreeBSD ports. It is exactly as much work as bundling them altogether, of course, but at least we avoid the impact on our distribution size. mk -- Marko Karppinen - http://homepage.mac.com/marko/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
Hi, On Thu, May 30, 2002 at 07:43:24AM +0300, Andi Gutmans wrote : But if libxml2 is a moving target and it's hard to stay in sync then it certainly sounds beneficial to take away this headache from our users. It seems we need to define 'hard to stay in sync'. The only hard thing it to install the latest RPM for your system or install the latest sources. IMHO this does not justify a bundling. To me, the whole thread is pointless and the onyl REAL reasons I've heard from Brad and Yasou are the hassle to install it [...] - Markus -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc Wishlist: http://guru.josefine.at/~mfischer/wishlist -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
Hi, On Thu, May 30, 2002 at 10:06:50AM +0300, Marko Karppinen wrote : Dan: If we start down this path of bundling external projects, why don't we just bundle every external project PHP supports to make it the easiest? This is just an absurd notion to bundle an actively developed/maintained piece of code. The headaches it will introduce are not worth the minor benefit. I think the solution would be to allow PECL to optionally fetch the libraries an extension depends on, quite like FreeBSD ports. It is exactly as much work as bundling them altogether, of course, but at least we avoid the impact on our distribution size. Honestly I see this being a point beyond the task of PECL. There are too many things which can get fucked up (I just see a secenery where someone accidantly installs libxml2 through PECL though he has it in the system but in a non-standard path). Really, this does not belong to PECL by all means. - Markus -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc Wishlist: http://guru.josefine.at/~mfischer/wishlist -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
Markus: Honestly I see this being a point beyond the task of PECL. There are too many things which can get fucked up (I just see a secenery where someone accidantly installs libxml2 through PECL though he has it in the system but in a non-standard path). Really, this does not belong to PECL by all means. I think I didn't make myself clear enough. I didn't mean that PECL should install system libraries; it could instead download php-specific copies of them (like ext/gd/libgd) and use them for building the extension binary *only*. This is what I meant when I said that it would be just as hard as actually bundling the libraries. There has already been talk about including binary versions of the extensions in PECL. Presumably they would also contain the dependencies. My proposal is to make the *complete* source to them available for building on the client side, too. And, just for the record, I also oppose the idea of bundling something as huge as libxml2 into the main distribution. mk -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
Hi, ok, missed that. But i hope you know this would only really work on Windows I guess. Even sharing binaries from one Linux distribution to another is not possible sometimes because of the different GLIBCs used. IMHO that cries for more work then there would be benefit for. System administration is task of the user. It always was and will always be. - Markus On Thu, May 30, 2002 at 12:12:15PM +0300, Marko Karppinen wrote : Markus: Honestly I see this being a point beyond the task of PECL. There are too many things which can get fucked up (I just see a secenery where someone accidantly installs libxml2 through PECL though he has it in the system but in a non-standard path). Really, this does not belong to PECL by all means. I think I didn't make myself clear enough. I didn't mean that PECL should install system libraries; it could instead download php-specific copies of them (like ext/gd/libgd) and use them for building the extension binary *only*. This is what I meant when I said that it would be just as hard as actually bundling the libraries. There has already been talk about including binary versions of the extensions in PECL. Presumably they would also contain the dependencies. My proposal is to make the *complete* source to them available for building on the client side, too. And, just for the record, I also oppose the idea of bundling something as huge as libxml2 into the main distribution. mk -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc Wishlist: http://guru.josefine.at/~mfischer/wishlist -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
On Thu, 30 May 2002, Marko Karppinen wrote: I think the solution would be to allow PECL to optionally fetch the libraries an extension depends on, quite like FreeBSD ports. While this idea would be excellent, any recent readings on the FreeBSD list you'll find the limitations of the ports collection (thus their continuous work on a new system). I like the ports system very much. But I don't see PHP moving to become an OS level version tracker. Which is very much what will be required to be implemented for this idea to work. I still stand on the ground that if a user/system-administrator wants capability ABC, they better be damn sure they know what they're doing, the benefits, the disadvantages, what version of software they are using, and what (if any) potential security holes that software opens up. Granted most people just say ./configure make install but then that is their choice to ignore the information. --- Dan KalowskyThe record shows, I took the blows. http://www.deadmime.org/~dankAnd did it my way. [EMAIL PROTECTED] - My Way, Frank Sinatra [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
Ignore that, Marko clarified his stance much better later. I really need to finish reading the overnight discussions before sending a reply. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
On Wed, May 29, 2002 at 10:53:38AM -0700, brad lafountain wrote: It was mentioned before about bundling libxml2 with php with expat or instead of expat. Where do we stand with this? I emailed the developer asking permission to bundle it if we choose to do it (no response yet). for the record, -1 from me on bundling libxml2 with php. imho, the disadvantages outweigh the benefits by far. -lukas -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
[EMAIL PROTECTED] wrote: The libxml project provides their own RPMs, so building them yourself is not really needed. Great! I'll check the spec file to see if I can use it out of box. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
--- [EMAIL PROTECTED] wrote: On Thu, 30 May 2002, Andi Gutmans wrote: I think that XML is a core technology and giving plugplay access to our users is important. Having bundled the MySQL library made it easier for people to get started with MySQL. Does that mean I think every library should be bundled with PHP? No, I don't. But if libxml2 is a moving target and it's hard to stay in sync then it certainly sounds beneficial to take away this headache from our users. It also means that other XML based extensions could use it by default. Of course it also depends how big it is. If we can strip it down a lot I'd be a +1. If it'd add 1 MB to our .tar.gz I would be against. THe normal source distribution is almost 2 MB... The 2M size has alot of stuff that we wouldn't need. Im sure we can get it down to under 500K. - Brad __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
On Thu, 30 May 2002, brad lafountain wrote: The 2M size has alot of stuff that we wouldn't need. Im sure we can get it down to under 500K. I still think 500kb is too much for something the most ppl already have installed. Derick --- Did I help you? http://www.jdimedia.nl/derick/link.php?url=giftlist Frequent ranting: http://www.jdimedia.nl/derick/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
On Thu, 2002-05-30 at 02:04, Markus Fischer wrote: On Thu, May 30, 2002 at 08:12:27AM +0900, Yasuo Ohgaki wrote : Brad Lafountain wrote: Ok, But take ext/domxml it requires a newerversion of libxml2. I didn't have it installed on my machine when i installed php. If we bundle say a specfic version of libxml2 that domxml depends on, then it won't matter how fast pased the development is, ext/domxml won't use it. We can obvisouly peridocially upgrade the version that is bundled and you can have an override if you want to use a different version that is installed on a system. As xml gets more and more popular i feel that domxml will be more and more popular. Build outta the box +1 for libxml2 bundle. This already discussed, isn't this? -1 It's very actively developed. What is the reason of shared libraries if we don't use it?! GD is a completely different story. I even think it's not necessary to bundle libmysqlclient because it's really installed everywhere where mysql is available. We bundle mysql for the very same reason Brad wants to bundle libxml2. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
We bundle mysql for the very same reason Brad wants to bundle libxml2. Except with MySQL we have a commitment from the MySQL developers themselves to maintain it and keep it current. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
On Thu, 2002-05-30 at 03:29, Yasuo Ohgaki wrote: I think we can remove expat bundle now.) Think again :-) Expat has been bundled for ages, and IMHO we should not drop it unless we have another bundled xml library and ext/xml can use that instead. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
On Thu, 2002-05-30 at 18:08, [EMAIL PROTECTED] wrote: On Thu, 30 May 2002, brad lafountain wrote: The 2M size has alot of stuff that we wouldn't need. Im sure we can get it down to under 500K. I still think 500kb is too much for something the most ppl already have installed. Having a too old version installed doesn't help much in this case. :-) If Brad is able to trim down libxml2 to a reasonable size, I'm +1 - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
At 08:46 30/05/2002 +0200, [EMAIL PROTECTED] wrote: On Thu, 30 May 2002, Andi Gutmans wrote: I think that XML is a core technology and giving plugplay access to our users is important. Having bundled the MySQL library made it easier for people to get started with MySQL. Does that mean I think every library should be bundled with PHP? No, I don't. But if libxml2 is a moving target and it's hard to stay in sync then it certainly sounds beneficial to take away this headache from our users. It also means that other XML based extensions could use it by default. Of course it also depends how big it is. If we can strip it down a lot I'd be a +1. If it'd add 1 MB to our .tar.gz I would be against. THe normal source distribution is almost 2 MB... In that case I'm against :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
On Thu, 30 May 2002, Rasmus Lerdorf wrote: Except with MySQL we have a commitment from the MySQL developers themselves to maintain it and keep it current. Which they do very often, isn't it Zak ;) But there is a point, there is much more familiarity between MySQL and PHP then between the libxml guys and PHP. Derick --- Did I help you? http://www.jdimedia.nl/derick/link.php?url=giftlist Frequent ranting: http://www.jdimedia.nl/derick/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
At 19:03 30/05/2002 +0200, [EMAIL PROTECTED] wrote: On Thu, 30 May 2002, Rasmus Lerdorf wrote: Except with MySQL we have a commitment from the MySQL developers themselves to maintain it and keep it current. Which they do very often, isn't it Zak ;) But there is a point, there is much more familiarity between MySQL and PHP then between the libxml guys and PHP. XML is an extremely important technology. I like the MS way where this kind of stuff works out of the box. It would also allow other extensions to use it and make XML support much more integrated in PHP. So if you can cut it down to something small I'm +1. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
lot I'd be a +1. If it'd add 1 MB to our .tar.gz I would be against. THe normal source distribution is almost 2 MB... In that case I'm against :) Andi xpat is 300K. If Brad can get it down to 500K, and we replace xpat, then we realy are not growing all that much. I'm for doing this since soap (in addition to other things) would greatly benefit from having this bundled. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
--- Stig S. Bakken [EMAIL PROTECTED] wrote: On Thu, 2002-05-30 at 18:08, [EMAIL PROTECTED] wrote: On Thu, 30 May 2002, brad lafountain wrote: The 2M size has alot of stuff that we wouldn't need. Im sure we can get it down to under 500K. I still think 500kb is too much for something the most ppl already have installed. Having a too old version installed doesn't help much in this case. :-) If Brad is able to trim down libxml2 to a reasonable size, I'm +1 Got it a little under 800k Just the c source alone was 500k. There are a few source files with 1 lines. I still would like to see it bundled. I do understand that libxml2 is being developed regulary but since domxml does require a semi-new version of libxml2 that most people don't have. I don't know when 2.4.14 was released but the date on the file server is 2/8/2002. Thats pretty recent. I don't/didn't have that version installed on my system. Pretty much every project that i work on uses some kinda xml processing I don't know if thats true for a majority of people or not but I definlty rely on it alot. If we bundle 2.4.14 we can change domxml's config script to detect the version on the system if its greater than 2.4.14 then it can link against that version if it isn't then it will use the bundled version. As far as upgrading the version that is bundled. How often or if ever do we need to. If changes in domxml require a newer version of libxml2 then thats when we can upgrade the bundled lib otherwise we wouldn't need to. From my understanding libxml2 is faster than expat? and all the things like ext/xml and ext/xmlrpc can be converted to libxml2? Since we do bundle expat i don't see the big problem with bundling libxml2. So the only down side I see is the filesize of php? I don't see that as too much of a problem but thats just my opnion too. I personally will take responsiblity for bundling and upgrading it. - Brad __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
Hi I still would like to see it bundled. I do understand that libxml2 is being developed regulary but since domxml does require a semi-new version of libxml2 that most people don't have. I don't know when 2.4.14 was released but the date on the file server is 2/8/2002. Thats pretty recent. Yep, 2.4.14 is from then. I don't/didn't have that version installed on my system. Pretty much every project that i work on uses some kinda xml processing I don't know if thats true for a majority of people or not but I definlty rely on it alot. If you compile php by yourself anyway, what's the problem with having to download another library and doing ./configure make make install for that. Ok, it's a little bit more work for you, but you're compiling anyway... If we bundle 2.4.14 we can change domxml's config script to detect the version on the system if its greater than 2.4.14 then it can link against that version if it isn't then it will use the bundled version. As far as upgrading the version that is bundled. How often or if ever do we need to. If changes in domxml require a newer version of libxml2 then thats when we can upgrade the bundled lib otherwise we wouldn't need to. did you read the changelog? almost every release has bugfixes and speed improvements. If that's the case with a new release, i see no reason not having to sync it. Therefore i think it's a PITA :) And since Daniel Veillard is almost certainly not in the mood of updating this by himself, someone of us has to take over this part (ok, you would do that..) If we don't include it, it's up to the system administrator to get the latest libxml2 libraries, if he wants bugs fixed and the fastest implementation. And it's really not that difficult to update libxml (did i say apt-get upgrade? but also with rpm-based distros it shouldn't be much of a hassle, since there are rpms on the xmlsoft server...) From my understanding libxml2 is faster than expat? I don't know. SAX-Parsing can't be that difficult to implement. But since there is no SAX support in ext/domxml, it's hard to compare,, and all the things like ext/xml and ext/xmlrpc can be converted to libxml2? don't know if ext/xmlrpc would benefit from libxml2, but ext/xml could be certainly ported to libxml. Since we do bundle expat i don't see the big problem with bundling libxml2. I see the problem with maintaining that and adding another 800kB,... I'm still -1 with that. (but i see the point in andis MS reference it works out of the box, maybe the PECL/bundling idea is not that bad, then we can just throw the libxml tarball in that... ) chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
At 19:29 30.05.2002, brad lafountain wrote: --- Stig S. Bakken [EMAIL PROTECTED] wrote: On Thu, 2002-05-30 at 18:08, [EMAIL PROTECTED] wrote: On Thu, 30 May 2002, brad lafountain wrote: The 2M size has alot of stuff that we wouldn't need. Im sure we can get it down to under 500K. I still think 500kb is too much for something the most ppl already have installed. Having a too old version installed doesn't help much in this case. :-) If Brad is able to trim down libxml2 to a reasonable size, I'm +1 Got it a little under 800k I would very much appreciate that and 800k is o.k. because the xml part will become a key technology very soon, meaning without xml, soap and such running out-a-box php will get lost. so for me +++1 Just the c source alone was 500k. There are a few source files with 1 lines. I still would like to see it bundled. I do understand that libxml2 is being developed regulary but since domxml does require a semi-new version of libxml2 that most people don't have. I don't know when 2.4.14 was released but the date on the file server is 2/8/2002. Thats pretty recent. I don't/didn't have that version installed on my system. Pretty much every project that i work on uses some kinda xml processing I don't know if thats true for a majority of people or not but I definlty rely on it alot. If we bundle 2.4.14 we can change domxml's config script to detect the version on the system if its greater than 2.4.14 then it can link against that version if it isn't then it will use the bundled version. As far as upgrading the version that is bundled. How often or if ever do we need to. If changes in domxml require a newer version of libxml2 then thats when we can upgrade the bundled lib otherwise we wouldn't need to. From my understanding libxml2 is faster than expat? and all the things like ext/xml and ext/xmlrpc can be converted to libxml2? Since we do bundle expat i don't see the big problem with bundling libxml2. So the only down side I see is the filesize of php? I don't see that as too much of a problem but thats just my opnion too. I personally will take responsiblity for bundling and upgrading it. - Brad __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
In regards to download size, I took a look at other languages: perl 6mb source python 6mb source activeperl 8.5mb binary activepython 7mb source, binaries are larger activetcl 8.5mb I don't think the increase of a half mb in php source size is that big a deal, esp. for something as important as xml. The only downside in increasing the size is the bandwidth requirements for php.net. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
On Thu, 30 May 2002, brad lafountain wrote: I personally will take responsiblity for bundling and upgrading it. Brad, Nothing personal (so please don't take it that way), but in my opinion this isn't a good enough assurance. Historically you will see people come and people go with Open Source development, and while you have a lot of free time to do this now, N months from now will you? As Rasmus stated earlier the reason the MySQL stuff is bundled is due to an assurance from the MySQL developers to keep it updated. They know their code inside and out. I'm not familiar with what you do or don't know, or what development you're active in either. Unless you were/are an active developer on the libxml code, the ability to introduce bugs completely dependent to the PHP bundle is increased considerably due to bad merges. I really see little to no advantage to this bundling yet. Only increasingly more reasons not to do this. --- Dan KalowskyThe record shows, I took the blows. http://www.deadmime.org/~dankAnd did it my way. [EMAIL PROTECTED] - My Way, Frank Sinatra [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
--- Dan Kalowsky [EMAIL PROTECTED] wrote: On Thu, 30 May 2002, brad lafountain wrote: I personally will take responsiblity for bundling and upgrading it. Brad, Nothing personal (so please don't take it that way), but in my opinion this isn't a good enough assurance. Historically you will see people come and people go with Open Source development, and while you have a lot of free time to do this now, N months from now will you? Free Time? Who says i have that? Months from now I honistly can't say what i'll be doing. For all I know i could get hit by a car. I don't plan on ditching my contributions anytime soon. But I don't see my contributions a factor in deciding if we should bundle libxml. We are only talking about a few cvs commands here! We aren't talking about a huge effort. As Rasmus stated earlier the reason the MySQL stuff is bundled is due to an assurance from the MySQL developers to keep it updated. They know their code inside and out. I'm not familiar with what you do or don't know, or what development you're active in either. Unless you were/are an active developer on the libxml code, the ability to introduce bugs completely dependent to the PHP bundle is increased considerably due to bad merges. I don't see bad merges a problem here. It's not like I would be applying patches or getting the latest and greates from libxml's cvs. Peridocially someone would just need to update the source files from the 'newest' release. But as I explained before besides bug fixes and speed increases you wouldn't get much from keeping totally up to date with the bundled libxml. And again.. its not like we are forcing the version on the user nor making it an inconvenionce for them if they already have libxml installed. I really see little to no advantage to this bundling yet. Only increasingly more reasons not to do this. I really dont see this. I don't know how much developement other people do but use xml/xml techiologies on a daily basis. I see this is the trend of many developers but I obvisouly cant speak for them. The ability to build outta the box is also what many system admins what to see, maybe not the hacker ones but the ones who just get the job done. I also know alot of managers that will pay for software just cuase it runs outta the box. No needing to depend on other software is installed. So with thoes two statements it makes total sence to go thru the process of bundling something as important as libxml. Ok we bundle gd... gd is very usefull for many sites/applications but common don't you feel that xml is a little bit more important than gd? The only downside here is the filesize of the source dist and a few developers already commented that it's not that big of a deal. Seriously we bundle expat why wouldn't we bundle libxml. It's way more usefull than expat. - Brad __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
At 16:39 30/05/2002 -0400, Dan Kalowsky wrote: On Thu, 30 May 2002, brad lafountain wrote: I personally will take responsiblity for bundling and upgrading it. Brad, Nothing personal (so please don't take it that way), but in my opinion this isn't a good enough assurance. Historically you will see people come and people go with Open Source development, and while you have a lot of free time to do this now, N months from now will you? As Rasmus stated earlier the reason the MySQL stuff is bundled is due to an assurance from the MySQL developers to keep it updated. They know their code inside and out. I'm not familiar with what you do or don't know, or what development you're active in either. Unless you were/are an active developer on the libxml code, the ability to introduce bugs completely dependent to the PHP bundle is increased considerably due to bad merges. I really see little to no advantage to this bundling yet. Only increasingly more reasons not to do this. Just to set the record straight, the MySQL guys haven't been very good at syncing the MySQL libraries in our tree. One fix I had to apply myself because they just didn't get to it. I don't really mind because there wasn't anything critical but that's what happened. I Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
Months from now I honistly can't say what i'll be doing. For all I know i could get hit by a car. I don't plan on ditching my contributions anytime soon. But I don't see my contributions a factor in deciding if we should bundle libxml. Exactly the unspoken point. While I'm not saying you will be ending your contributions anytime soon, at the point if/when you do there is no assurance of continued updating. As Andi pointed out, even with this assurance from the MySQL team, it doesn't always happen. I don't see bad merges a problem here. It's not like I would be applying patches or getting the latest and greates from libxml's cvs. Peridocially someone would just need to update the source files from the 'newest' release. Prune'ing the source from 2MB to 800K is a rather drastic size decrease. That will be where any maintaince and what not will be required. It would not be just update to the 'newest' release. It would also require ensuring that these are still the only files necessary, the build still works, and so on. Possibly minor work, but one which will still take time from someone which really doesn't need to be expended. I don't know how much developement other people do but use xml/xml techiologies on a daily basis. I see this is the trend of many developers but I obvisouly cant speak for them. I don't disagree with XML becoming a more essential technology for development. But because it is becoming a more essential technology I don't see a reason to bundle a PHP specific version of a commonly used library. Especially while it is still actively maintained, and more core services and functionalities are beginning to require it. The ability to build outta the box is also what many system admins what to see, maybe not the hacker ones but the ones who just get the job done. I also know alot of managers that will pay for software just cuase it runs outta the box. No needing to depend on other software is installed. I wish this point would be dropped, if only for a basic problem with this arguement. PHP cannot (nor should it in my opinion) be a build outta the box process. Why? Because it would require bundling a large number of external libraries. PHP will always depend upon external libraries. That is how programming languages work, which is what PHP has/is become(ing). What, for example, makes libxml any more special than say iODBC? iODBC runs on many (if not all) platforms. It provides a universal ODBC access to countless databases. It supports ODBC v3.7 compliant calls, thus we could update the PHP ODBC routines from 2.0 to 3.7. ODBC was/is considered an essential technology for database access as well. These points are all similiar to those being made for including libxml. The main point of this being, where does the PHP environment draw the line and say No this should be or Not this shouldn't be bundled? If you want an out of the box solution, this line will never be drawn, and we should just start bundling everything now. If you say only specific libraries should be who gets to decide, and what is the criteria for inclusion? It is far easier and a more sane option to not even begin that path, or to continue further down that path. Ok we bundle gd... gd is very usefull for many sites/applications but common don't you feel that xml is a little bit more important than gd? It's not a point of if gd is more important than XML. gd is not, nor has it been for a long time, actively maintained. PHP's bug database was beginning to fill up with bug reports about gd not working. Patches were being done and maintained on various sites to fix bugs internal to gd itself. Yet there were no official releases to incorporate them. While I don't completely agree with the bundling of gd either, I also didn't have any better solution to suggest. This hasn't been the case with the libxml. Any bugs and patches submited to the development team are incorporated (provided their validity) into an official release. There are no external sites with patches (that I know of offhand) to fix a specific function within the libxml library. Seriously we bundle expat why wouldn't we bundle libxml. It's way more usefull than expat. I don't agree with the fact that expat is bundled either. But that is something I wasn't around to argue, or if I was I somehow missed it entirely. As of right now, that isn't likely to change anytime in the future either. I'm normally extremely quiet on the list unless I have questions or see something I disagree with. Enabling by default and bundling external code are two things I believe should just be avoided. --- Dan KalowskyThe record shows, I took the blows. http://www.deadmime.org/~dankAnd did it my way. [EMAIL PROTECTED] - My Way, Frank Sinatra [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit:
Re: [PHP-DEV] bundling libxml2 / bundling locations
On Wed, 29 May 2002, brad lafountain wrote: Hello all, It was mentioned before about bundling libxml2 with php with expat or instead of expat. Where do we stand with this? I emailed the developer asking permission to bundle it if we choose to do it (no response yet). öhm, libxml2 is a relatively huge project with a fast developement cycle.. I don't see the point in bundling that with php. It's actively maintained (not as for example gd), we don't need any patches to get it running and it comes with most (all?) distros (not installed by default everywhere, but it's available). And installation from source is also no pain at all... chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
Ok, But take ext/domxml it requires a newerversion of libxml2. I didn't have it installed on my machine when i installed php. If we bundle say a specfic version of libxml2 that domxml depends on, then it won't matter how fast pased the development is, ext/domxml won't use it. We can obvisouly peridocially upgrade the version that is bundled and you can have an override if you want to use a different version that is installed on a system. As xml gets more and more popular i feel that domxml will be more and more popular. Build outta the box - Brad --- Christian Stocker [EMAIL PROTECTED] wrote: On Wed, 29 May 2002, brad lafountain wrote: Hello all, It was mentioned before about bundling libxml2 with php with expat or instead of expat. Where do we stand with this? I emailed the developer asking permission to bundle it if we choose to do it (no response yet). öhm, libxml2 is a relatively huge project with a fast developement cycle.. I don't see the point in bundling that with php. It's actively maintained (not as for example gd), we don't need any patches to get it running and it comes with most (all?) distros (not installed by default everywhere, but it's available). And installation from source is also no pain at all... chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
brad lafountain wrote: Ok, But take ext/domxml it requires a newerversion of libxml2. I didn't have it installed on my machine when i installed php. If we bundle say a specfic version of libxml2 that domxml depends on, then it won't matter how fast pased the development is, ext/domxml won't use it. We can obvisouly peridocially upgrade the version that is bundled and you can have an override if you want to use a different version that is installed on a system. As xml gets more and more popular i feel that domxml will be more and more popular. I'd make it an optional download, because there are always people like me who have all the libraries already installed with their distro. People with non-deb distros or who are lacking skills with Linux but want to do it anyway would definately benefit from this. It would be for pure convinience, like all the precompiled libraries bundled with the Windows-download, gdlib is an entirely different matter. regards Wagner -- When did ignorance become a point of view? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
Brad Lafountain wrote: Ok, But take ext/domxml it requires a newerversion of libxml2. I didn't have it installed on my machine when i installed php. If we bundle say a specfic version of libxml2 that domxml depends on, then it won't matter how fast pased the development is, ext/domxml won't use it. We can obvisouly peridocially upgrade the version that is bundled and you can have an override if you want to use a different version that is installed on a system. As xml gets more and more popular i feel that domxml will be more and more popular. Build outta the box +1 for libxml2 bundle. This already discussed, isn't this? ext/xml/libxml2 ? Odd location, but domxml support without xml does not make much sense to me. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
On Thu, May 30, 2002 at 08:12:27AM +0900, Yasuo Ohgaki wrote : Brad Lafountain wrote: Ok, But take ext/domxml it requires a newerversion of libxml2. I didn't have it installed on my machine when i installed php. If we bundle say a specfic version of libxml2 that domxml depends on, then it won't matter how fast pased the development is, ext/domxml won't use it. We can obvisouly peridocially upgrade the version that is bundled and you can have an override if you want to use a different version that is installed on a system. As xml gets more and more popular i feel that domxml will be more and more popular. Build outta the box +1 for libxml2 bundle. This already discussed, isn't this? -1 It's very actively developed. What is the reason of shared libraries if we don't use it?! GD is a completely different story. I even think it's not necessary to bundle libmysqlclient because it's really installed everywhere where mysql is available. - Markus -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc Wishlist: http://guru.josefine.at/~mfischer/wishlist -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
On Thu, May 30, 2002 at 09:58:31AM +0900, Yasuo Ohgaki wrote : Markus Fischer wrote: Build outta the box +1 for libxml2 bundle. This already discussed, isn't this? -1 It's very actively developed. What is the reason of shared libraries if we don't use it?! GD is a completely different story. I even think it's not necessary to bundle libmysqlclient because it's really installed everywhere where mysql is available. I undstand libxml2 develpment is very active. That's the one of the reason why I prefer to bundle. For example, I have to build libxml RPM by myself to install PHP 4.3.0, since it requires too new libxml2 :( Just another RPM build, though. So? What is wrong with that?! I don't install compiler to servers just in case cracker got access to my boxes. I think most of us don't install compiler to servers. If we go with this paradigm we'ld have to bundle everything with PHP. Typically, administrators of such systems already live with that they have to rebuild and update packages. - Markus -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc Wishlist: http://guru.josefine.at/~mfischer/wishlist -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
Markus Fischer wrote: On Thu, May 30, 2002 at 09:58:31AM +0900, Yasuo Ohgaki wrote : Markus Fischer wrote: Build outta the box +1 for libxml2 bundle. This already discussed, isn't this? -1 It's very actively developed. What is the reason of shared libraries if we don't use it?! GD is a completely different story. I even think it's not necessary to bundle libmysqlclient because it's really installed everywhere where mysql is available. I undstand libxml2 develpment is very active. That's the one of the reason why I prefer to bundle. For example, I have to build libxml RPM by myself to install PHP 4.3.0, since it requires too new libxml2 :( Just another RPM build, though. So? What is wrong with that?! Just a pain to install :) I don't install compiler to servers just in case cracker got access to my boxes. I think most of us don't install compiler to servers. If we go with this paradigm we'ld have to bundle everything with PHP. Typically, administrators of such systems already live with that they have to rebuild and update packages. Not really, we just need to bundle libs that may have conflicts. GD is one, and libxml2 is another. (libxml2 changes too frequently and PHP requires specific version including patch level release. I think we can remove expat bundle now.) Most of us here have not problems to create custom packages for ourselves. Just matter of ease of use. -- Yasuo Ohgaki __ Do You Yahoo!? Yahoo! BB is Broadband by Yahoo! http://bb.yahoo.co.jp/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
My point of view is domxml does require a newish version of libxml2. It't not going to hurt if we bundle that version with php. The configure script can even detect a version that is installed on the system. If its greater than the packaged one then it can use that one instead alsogive the user to overide the bundled libxml2 --enable-domxml=/path/to/new/xml. I really don't see any ill effects with bundling. We bundle for the people don't regulary upgrade software and we allow auto config/overriding for people that do. Why do you think that .net will do so good (becides m$ forcing it on us). They run one installer and bingo everything works. People will say its easy to setup. - Brad --- Markus Fischer [EMAIL PROTECTED] wrote: On Thu, May 30, 2002 at 08:12:27AM +0900, Yasuo Ohgaki wrote : Brad Lafountain wrote: Ok, But take ext/domxml it requires a newerversion of libxml2. I didn't have it installed on my machine when i installed php. If we bundle say a specfic version of libxml2 that domxml depends on, then it won't matter how fast pased the development is, ext/domxml won't use it. We can obvisouly peridocially upgrade the version that is bundled and you can have an override if you want to use a different version that is installed on a system. As xml gets more and more popular i feel that domxml will be more and more popular. Build outta the box +1 for libxml2 bundle. This already discussed, isn't this? -1 It's very actively developed. What is the reason of shared libraries if we don't use it?! GD is a completely different story. I even think it's not necessary to bundle libmysqlclient because it's really installed everywhere where mysql is available. - Markus -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc Wishlist: http://guru.josefine.at/~mfischer/wishlist __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
I think that XML is a core technology and giving plugplay access to our users is important. Having bundled the MySQL library made it easier for people to get started with MySQL. Does that mean I think every library should be bundled with PHP? No, I don't. But if libxml2 is a moving target and it's hard to stay in sync then it certainly sounds beneficial to take away this headache from our users. It also means that other XML based extensions could use it by default. Of course it also depends how big it is. If we can strip it down a lot I'd be a +1. If it'd add 1 MB to our .tar.gz I would be against. Andi At 18:35 29/05/2002 -0700, brad lafountain wrote: My point of view is domxml does require a newish version of libxml2. It't not going to hurt if we bundle that version with php. The configure script can even detect a version that is installed on the system. If its greater than the packaged one then it can use that one instead alsogive the user to overide the bundled libxml2 --enable-domxml=/path/to/new/xml. I really don't see any ill effects with bundling. We bundle for the people don't regulary upgrade software and we allow auto config/overriding for people that do. Why do you think that .net will do so good (becides m$ forcing it on us). They run one installer and bingo everything works. People will say its easy to setup. - Brad --- Markus Fischer [EMAIL PROTECTED] wrote: On Thu, May 30, 2002 at 08:12:27AM +0900, Yasuo Ohgaki wrote : Brad Lafountain wrote: Ok, But take ext/domxml it requires a newerversion of libxml2. I didn't have it installed on my machine when i installed php. If we bundle say a specfic version of libxml2 that domxml depends on, then it won't matter how fast pased the development is, ext/domxml won't use it. We can obvisouly peridocially upgrade the version that is bundled and you can have an override if you want to use a different version that is installed on a system. As xml gets more and more popular i feel that domxml will be more and more popular. Build outta the box +1 for libxml2 bundle. This already discussed, isn't this? -1 It's very actively developed. What is the reason of shared libraries if we don't use it?! GD is a completely different story. I even think it's not necessary to bundle libmysqlclient because it's really installed everywhere where mysql is available. - Markus -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc Wishlist: http://guru.josefine.at/~mfischer/wishlist __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
