Subject: Changes to use new PEAR features (channels and package.xml v2)
To: None <tech-pkg@netbsd.org>
From: Christopher W. Richardson <cwr@nexthop.com>
List: tech-pkg
Date: 06/25/2007 12:35:43
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I've been poking around for a while now, trying to create a
package for PEAR Role_Web from pearified.com, and I've come to
two (possibly erroneous) conclusions:

	1) Our PEAR stuff is not set up to use channels other
           than the default ones which come with pear
           (pear.php.net, pecl.php.net, and URI)

        2) pear_plist.php does not really handle package.xml v2
           packages

I'm willing to work on both of these (assuming I'm right in my
diagnosis), but I'm not exactly a PHP/PEAR expert, and I also
have some generic questions about how to handle the channels.

First, for channels, there are already a number of them out
there, and I'm sure the list is only going to grow (q.v.,
http://pear.php.net/channels/).  Off the top of my head, there
are at least three ways to handle this:

	a) add "meta" packages for each channel, and use those
	   packages as dependencies for any pear packages from
	   the channels

	b) add logic in lang/php/pear.mk to properly handle
	   channels (adding some sort of CHANNEL variable, and
	   doing pre-install and post-deinstall work to attempt
	   to register or unregister the channel from pear)

        c) let each package handle channel issues on its own

Anyone have any thoughts/preferences/other suggestions on the
above?

Second, AFAICT, pear_plist.php uses infoFromAny to extract the
file list and create the PLIST for pear packages.  The comment
for that function says, "@deprecated use
PEAR_PackageFile->fromAnyFile() instead".  Internally,
infoFromAny does use the PEAR_PackageFile routines, but before
returning, it runs things through _postProcessValidPackagexml,
which strips most of the v2 file stuff and returns something like
a v1 array.  I played around with using
PEAR_PackageFile->fromAnyFile() on my own, unsuccessfully, so
before I go farther down this path, I wanted to get some
concurrence that we should move to using the new calls directly
(and possibly some suggestions on how to do so).

Cheers,
Chris

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFGf+62P65RBOOHTzERAsnrAJ9CWiceLraFNy8ROiNHMTrYypxlkgCeOdbg
NRxEbZ1bijgAb55y4IrE51c=
=LYqr
-----END PGP SIGNATURE-----