[RFC] Binary pecl packages

Hello Tomas, Why not using RPMs? Only windows is a problem, isn't it ? regards marcus Thursday, June 19, 2003, 1:19:36 AM, you wrote: TVVC> What about to start discussing about managment of binary pecl TVVC> packages? TVVC> I'm not the best person for listing the requirements, but here are some TVVC> ideas: TVVC> pecl package name TVVC> ----------------- TVVC> The name of the extension would be: TVVC> peclfoo-bin-<OS>-<ARCH>-3.1.2-<STATE>.tgz TVVC> The os (Operating system) and arch (CPU type), would be the value TVVC> returned by the OS_Guess class. STATE is a valid PEAR_Common package TVVC> state. TVVC> package creation TVVC> ---------------- TVVC> pear build -b peclfoo-3.1.2.tgz TVVC> The -b (or --bin) option generates the package containing only the TVVC> compiled extension and the files marked with role "php", "doc", "test", TVVC> "data" or "script" with the original package.xml modified TVVC> automagically (explained in the next point). TVVC> Without args it compiles the extension as it does nowadays. TVVC> An idea would be to create a COMPILED_AT.txt file with some data about TVVC> the env where the extension was compiled at, like the TVVC> php version, the php_uname(), the extra libs versions, os vendor TVVC> version, /etc/shadow file, etc. TVVC> package.xml TVVC> ----------- TVVC> As a binary release shares the same release data with the source TVVC> distrib, except the filelist (please confirm if an TVVC> extension compiled may have different dependencies across different TVVC> platforms), the same package.xml file could be used for all kind of TVVC> distribs. Let's say something like: TVVC> <release> TVVC> <version>... TVVC> <date> TVVC> <notes> TVVC> <filelist>.. TVVC> <file role="ext" os="" arch=""> TVVC> </release> TVVC> installation TVVC> ------------ TVVC> pear install -b peclfoo (download and install the binary distrib of TVVC> peclfoo for your current OS-ARCH) TVVC> pear install peclfoo-bin-<OS>-<ARCH>-3.1.2-<STATE>.tgz TVVC> All the files with role="ext" would be installed TVVC> in "ext_dir" (pear cmd setting). The user can config it with "pear config-set ext_dir=XXX". TVVC> If this var is not explicitly set, the following will be used for TVVC> finding a default location: TVVC> if (getenv('PHP_PEAR_EXTENSION_DIR')) { TVVC> define('PEAR_CONFIG_DEFAULT_EXT_DIR', getenv('PHP_PEAR_EXTENSION_DIR')); TVVC> } else { TVVC> if (ini_get('extension_dir')) { TVVC> define('PEAR_CONFIG_DEFAULT_EXT_DIR', ini_get('extension_dir')); TVVC> } elseif (defined('PEAR_EXTENSION_DIR') && @is_dir(PEAR_EXTENSION_DIR)) { TVVC> define('PEAR_CONFIG_DEFAULT_EXT_DIR', PEAR_EXTENSION_DIR); TVVC> } elseif (defined('PHP_EXTENSION_DIR')) { TVVC> define('PEAR_CONFIG_DEFAULT_EXT_DIR', PHP_EXTENSION_DIR); TVVC> } else { TVVC> define('PEAR_CONFIG_DEFAULT_EXT_DIR', '.'); TVVC> } TVVC> } TVVC> Listing in the web TVVC> ------------------ TVVC> A new column "Type" should be added to the release listing under the TVVC> package home page at pear.php.net, saying that the package is a binary TVVC> distrib compiled for OS X and ARCH Y or sources.

On Thu, Jun 19, 2003 at 01:19:36AM +0200, Tomas V.V.Cox wrote:

I think 'pear dist' would be a more appropriate name for this operation (or maybe just an extension of 'pear package').

I'd suggest BUILDINFO.txt. I'm not sure if this is entirely necessary, but I can see where it would be useful. I'll also point you to distutils[1]. The Python folks spent a lot of time thinking about these kinds of problems, and the result is a quite good system. [1] http://www.python.org/doc/current/lib/module-distutils.html

When I get a little more time (in about 2 months!) I will be completing the work that I started on the .MSI installer generator for PHP. This will generate an installer for the PHP distribution (including PEAR) based on the .zip binary distros cooked by the snaps machine and meta data from the source tree. One of the things that should be possible is generating additional .MSI files for PECL packages. From the example below, the 'peclfoo' package would be generated as 'peclfoo-3.1.2-<STATE>.msi'. Since .msi is "equivalent" to .rpm, we would then have the benefits of a system supported package manager; the main thing that I can think of is that it will handle upgrading extensions that are in use (if the user has enough privileges) by being able to stop the web server while it updates the file, or perhaps scheduling a restart if that is required. --Wez.

Hi, On Thu, Jun 19, 2003 at 01:19:36AM +0200, Tomas V.V.Cox wrote : [...]

[...] The only thing I was really missing here (unless I managed to miss it in the text only) is different PHP versions. A binary built for PHP 4.0 wouldn't work with PHP 4.3 for example due to interface changes (bad example because not only the API changed but also some internals afaik; neverthless). I don't know if it's a good idea to show the version of PHP the binary was compiled against, but somehow it needs to be known if the binary is compatible at all. For example mod_ssl [1] always includes the version number of the Apache server it works with: 21-Mar-2003: Released 2.8.14-1.3.27: Important bugfixes. So, with a quick look on the filename you know if it's compiled against your PHP version or not. - Markus