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-<OS>-<ARCH>-3.1.2-<STATE>.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-<OS>-<ARCH>-3.1.2-<STATE>.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
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, thephp_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/)
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').
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 <type>] [-b] [-s] <package>
-t <type> 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 :)
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, thephp_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 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
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').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 <type>] [-b] [-s] <package>
-t <type> 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/)
Let's say something like:
pear package [-t <type>] [-b] [-s] <package>
-t <type> The type of package you want to generate (pear, rpm,
msi, etc)
-b Specifies a binary package
-d Only generate the description package fileI 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/
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.
pecl package name
The name of the extension would be:
peclfoo-bin-<OS>-<ARCH>-3.1.2-<STATE>.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.
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.
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
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-<OS>-<ARCH>-3.1.2-<STATE>.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
On Fri, 20 Jun 2003 01:56:41 +0200
Markus Fischer mfischer@gjat.josefine.at 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