Re: PEAR Package Requirements and binarycloud
| From: | Stig S. Bakken | Date: | Mon, 13 Jan 2003 23:47:48 +0000 |
| Subject: | Re: PEAR Package Requirements and binarycloud | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-12378@lists.php.net to get a copy of this message | ||
On Mon, 2003-01-13 at 01:02, Alex Black wrote:
> hi guys,
>
> I think we'd like to use the PEAR package system for binarycloud. Certainly
> for compatibility and "resource sharing" it seems like the best path.
>
> However, I do not have a sophisticated understanding of the installer, and I
> wonder if anyone would be willing to respond to this message with a fairly
> detailed explanation of the workings and requirements of the PEAR installer
> + package xml.
>
> Specifically:
> -Package dependencies
The current system with <dep> tags in package.xml files should work well
for at least package, extension and php version dependencies.
Dependencies have a type, a relation and possibly a version number. The
types supported today are:
pkg (package dependencies)
ext (extension dependencies)
php (PHP version dependencies)
prog (external program dependencies)
os (for example "windows-*" or "*-i386")
zend (Zend version dependencies)
The package DTD also defines "ldlib", "rtlib", "websrv" and
"sapi", but
these are not implemented yet ("sapi" will most likely never be).
The "relation" attribute of a dependency is by default "has", but may
also be "lt" (less than), "le", "eq", "gt", "ge"
or "ne" (not equal).
The version attribute is used when the relation is any of the
less/greater ones.
The weakness of PEAR's dependency implementation today is that it does
not know about cascading dependencies in order to present to the user a
full report on what dependencies need to be satisfied before he starts
installing anything. This is not a trivial task though, and I decided
to put it off until after 1.0 was out.
> -Build and preprocessing
No preprocessing, only validation. The only build process involved is
in the "pear package" command that re-generates the package.xml file
with calculated md5 checksums, and makes a tarball.
> -Remote installs
Just an idea so far: The installer has a "frontend" concept that lets
you plug different interfaces on top. We have a CLI, Gtk and web
interface today, adding an XML-RPC or SOAP frontend should not be too
difficult.
> -Required files "in" a package (like package.xml, others?)
Only package.xml is required.
> This is for my benefit, as well as the binarycloud-dev list's benefit.
>
> If the pear package system fits what we're doing (as I hope it does) we'll
> do what's necessary immediately to turn binarycloud into a PEAR package
> hierarchy that's installable.
>
> Then Phing (our build system) can take care of configuring and building
> those packages.
Where can I learn about Phing?
- Stig