# [RFC] Binary pecl packages - Thread: https://externals.io/message/2397 - Original archive: https://news-web.php.net/php.internals/2397 - Started by Tomas V.V.Cox on 2003-06-18T23:19:36+00:00 - Messages: 10 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #2397 — Tomas V.V.Cox — 2003-06-18T23:19:36+00:00 URL: https://externals.io/message/2397#2397 What about to start discussing about managment of binary pecl packages? I'm not the best person for listing the requirements, but here are some ideas: pecl package name ----------------- The name of the extension would be: peclfoo-bin---3.1.2-.tgz The os (Operating system) and arch (CPU type), would be the value returned by the OS_Guess class. STATE is a valid PEAR_Common package state. package creation ---------------- pear build -b peclfoo-3.1.2.tgz The -b (or --bin) option generates the package containing only the compiled extension and the files marked with role "php", "doc", "test", "data" or "script" with the original package.xml modified automagically (explained in the next point). Without args it compiles the extension as it does nowadays. An idea would be to create a COMPILED_AT.txt file with some data about the env where the extension was compiled at, like the php version, the `php_uname()`, the extra libs versions, os vendor version, /etc/shadow file, etc. package.xml ----------- As a binary release shares the same release data with the source distrib, except the filelist (please confirm if an extension compiled may have different dependencies across different platforms), the same package.xml file could be used for all kind of distribs. Let's say something like: ... .. installation ------------ pear install -b peclfoo (download and install the binary distrib of peclfoo for your current OS-ARCH) pear install peclfoo-bin---3.1.2-.tgz All the files with role="ext" would be installed in "ext_dir" (pear cmd setting). The user can config it with "pear config-set ext_dir=XXX". If this var is not explicitly set, the following will be used for finding a default location: if (getenv('PHP_PEAR_EXTENSION_DIR')) { define('PEAR_CONFIG_DEFAULT_EXT_DIR', getenv('PHP_PEAR_EXTENSION_DIR')); } else { if (ini_get('extension_dir')) { define('PEAR_CONFIG_DEFAULT_EXT_DIR', ini_get('extension_dir')); } elseif (defined('PEAR_EXTENSION_DIR') && @is_dir(PEAR_EXTENSION_DIR)) { define('PEAR_CONFIG_DEFAULT_EXT_DIR', PEAR_EXTENSION_DIR); } elseif (defined('PHP_EXTENSION_DIR')) { define('PEAR_CONFIG_DEFAULT_EXT_DIR', PHP_EXTENSION_DIR); } else { define('PEAR_CONFIG_DEFAULT_EXT_DIR', '.'); } } Listing in the web ------------------ A new column "Type" should be added to the release listing under the package home page at pear.php.net, saying that the package is a binary distrib compiled for OS X and ARCH Y or sources. -- Tomas V.V.Cox mailto:cox@idecnet.com --- ## #2399 — Rasmus Lerdorf — 2003-06-18T23:29:22+00:00 URL: https://externals.io/message/2397#2399 > Why not using RPMs? Only windows is a problem, isn't it ? Windows is the primary platform we need binaries for. -Rasmus --- ## #2408 — Jon Parise — 2003-06-19T02:27:44+00:00 URL: https://externals.io/message/2397#2408 · In reply to: #2397 > package creation > ---------------- > > pear build -b peclfoo-3.1.2.tgz > > The -b (or --bin) option generates the package containing only the > compiled extension and the files marked with role "php", "doc", "test", > "data" or "script" with the original package.xml modified > automagically (explained in the next point). I think 'pear dist' would be a more appropriate name for this operation (or maybe just an extension of 'pear package'). > An idea would be to create a COMPILED_AT.txt file with some data about > the env where the extension was compiled at, like the > php version, the `php_uname()`, the extra libs versions, os vendor > version, /etc/shadow file, etc. 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 -- Jon Parise (jon@php.net) :: The PHP Project (http://www.php.net/) --- ## #2414 — Wez Furlong — 2003-06-19T06:42:16+00:00 URL: https://externals.io/message/2397#2414 · In reply to: #2397 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-.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. > pecl package name > ----------------- > > The name of the extension would be: > > peclfoo-bin---3.1.2-.tgz > > The os (Operating system) and arch (CPU type), would be the value > returned by the OS_Guess class. STATE is a valid PEAR_Common package > state. --- ## #2416 — Tomas V.V.Cox — 2003-06-19T11:11:51+00:00 URL: https://externals.io/message/2397#2416 · In reply to: #2414 > 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-.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. Could this .msi generator be integrated into the pear cmd? A "pear makemsi" command would be cool. -- Tomas V.V.Cox mailto:cox@idecnet.com --- ## #2417 — Tomas V.V.Cox — 2003-06-19T11:59:35+00:00 URL: https://externals.io/message/2397#2417 · In reply to: #2408 > > > […] > I think 'pear dist' would be a more appropriate name for this > operation (or maybe just an extension of 'pear package'). Umm, yes, maybe it's better to just use "package". We have now native pear packages, rpm, msi is planned and others will surely come. Additionally we can generate the package description file and also call the tools for generating the whole package. Let's say something like: pear package [-t ] [-b] [-s] -t The type of package you want to generate (pear, rpm, msi, etc) -b Specifies a binary package -d Only generate the description package file You could even do a "pear package -t pear -d foo.tgz" to generate the package.xml file, at least the skeleton for hacking :) > > […] > I'd suggest BUILDINFO.txt. I'm not sure if this is entirely > necessary, but I can see where it would be useful. I personally met with some situations with non working RPMs, where I missed a lot this info. It's just a helper file, even suitable for better bug reporting. Umm, that takes me to the idea of a new "pear bugreport" command ;) > 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 Thanks, good info to look at. -- Tomas V.V.Cox mailto:cox@idecnet.com --- ## #2444 — Jon Parise — 2003-06-19T19:50:02+00:00 URL: https://externals.io/message/2397#2444 · In reply to: #2417 > > […] > > > […] > > Umm, yes, maybe it's better to just use "package". We have now native > pear packages, rpm, msi is planned and others will surely come. > Additionally we can generate the package description file and also > call the tools for generating the whole package. > > Let's say something like: > > pear package [-t ] [-b] [-s] > > -t The type of package you want to generate (pear, rpm, > msi, etc) > -b Specifies a binary package > -d Only generate the description package file I think this sounds good. The 'pear makerpm' command could be deprecated in favor of using the above, and this scheme allows more flexibility moving forward. -- Jon Parise (jon@php.net) :: The PHP Project (http://www.php.net/) --- ## #2451 — mfischer@gjat.josefine@Markus Fischer — 2003-06-19T23:56:41+00:00 URL: https://externals.io/message/2397#2451 · In reply to: #2397 Hi, On Thu, Jun 19, 2003 at 01:19:36AM +0200, Tomas V.V.Cox wrote : [...] > pecl package name > ----------------- > > The name of the extension would be: > > peclfoo-bin---3.1.2-.tgz > > The os (Operating system) and arch (CPU type), would be the value > returned by the OS_Guess class. STATE is a valid PEAR_Common package > state. [...] 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 --- ## #2452 — Pierre-Alain Joye — 2003-06-20T00:00:13+00:00 URL: https://externals.io/message/2397#2452 · In reply to: #2451 On Fri, 20 Jun 2003 01:56:41 +0200 Markus Fischer wrote: > 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. Sounds good too. And we already have the php version dependencies management. pierre --- ## #2456 — Martin Jansen — 2003-06-20T06:56:30+00:00 URL: https://externals.io/message/2397#2456 · In reply to: #2444 > > > […] > > I think this sounds good. The 'pear makerpm' command could be > deprecated in favor of using the above, and this scheme allows more > flexibility moving forward. Agreed. Just a minor note: If the -t option isn't specified, it should default to "-t pear", as packaging this format will happen most times, imo. -- - Martin Martin Jansen http://martinjansen.com/