Re: PEAR Package Requirements and binarycloud

From: 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

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