Re: PEAR and PHP 5

From: Date: Thu, 10 Apr 2003 20:38:39 +0000
Subject: Re: PEAR and PHP 5
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-15105@lists.php.net to get a copy of this message
On Thu, 2003-04-10 at 16:17, George Schlossnagle wrote: > On Thursday, April 10, 2003, at 07:01 AM, Stig S. Bakken wrote: > > > > Each release may have several files associated. Today there is only > > one, but if/when we start distributing binary builds of PECL packages > > there will obviously be several. This could be done with the same > > approach. When you upload a PHP 4 package, the original, unmodified > > PHP > > 4 version is stored in one .tgz file, and a PHP 5 version with > > translated code in another. Which file you actually get when > > requesting > > "Foo-1.0.tgz" is determined by the "get" script on pear.php.net. If > > your installer says it's installing for PHP 5, it will be given the > > Foo-1.0.php5.tgz tarball instead. > > > > It could be done by the packager, but that gives us a much higher > > bugfix/new-feature latency for the code translation, since everyone > > have > > to upgrade the installer. Could cause a chicken-and-egg situation if > > we're not very careful. Doing it on the server means a single place to > > upgrade and re-formatting any packages that may have been bad. > > I think you misunderstood me. I meant that it should be done by the > packager when the author prepares a pear tarball for upload. Doing it > automgaically on upload seems dangerous to me because you may end up > with huge numbers of experimental revisions as people work around the > (supposed) bugs/nuances in the translation system. The author should > have a good and easy way of checking the translation of their code > _before_ they upload it. Good point. So translation should at least be possible from the installer. But we should still be able to do it automatically during upload, or at least I would set that as the goal. If there is too much hassle creating translations, I'm afraid some maintainers choose not to battle with it. > The PECL problem is somewhat intractable, right? Somewhat. Since we have both OS and API numbers to deal with, we will need N*M binary files for each release, depending on how many PHP releases that need to be supported. Anyone feel like setting up a semi-automated compile farm? :-) - Stig

« previous php.pear.dev (#15105) next »