-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OK,

I've played around with this a little more, and it appears that
fixing things so that the *.reg file is properly in the PLIST
fixes my second issue -- but that still leaves the first one: 

"Christopher W. Richardson" <cwr@nexthop.com> writes:

> 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?

I've managed to get around the second issue by patching
lang/php/pear_plist.php:

cwr@ns$cvs diff pear_plist.php
Index: pear_plist.php
===================================================================
RCS file: /cvsroot/pkgsrc/lang/php/pear_plist.php,v
retrieving revision 1.4
diff -r1.4 pear_plist.php
14,17c14,30
< if (!empty($info['attribs']) && $info['attribs']['version'] ==
'2.0')
<       $pkg = $info['name'];
< else
<       $pkg = $info['package'];
- ---
> #
> # Read in package.xml using new API, and extract channel
> information
> $z = &PEAR_Config::singleton();
> $package = new PEAR_PackageFile($z);
> $pf = $package->fromAnyFile("$WRKSRC/package.xml",
> PEAR_VALIDATE_NORMAL);
>
> $version = $pf->getPackagexmlVersion();
>
> #
> # Use new method to get package name and channel info
> if ($version == '1.0')
>         $pkg_name = $pf['name'];
> else {
>         $pkg = $pf->_packageInfo['name'];
>         $channel = $pf->_packageInfo['channel'];
> }
>
20c33,38
< echo "$PEAR_LIB/.registry/".strtolower($pkg).".reg\n";
- ---
> if (($version == '1.0') || ($channel == 'pear.php.net'))
>         echo "$PEAR_LIB/.registry/".strtolower($pkg).".reg\n";
> else
>         echo "$PEAR_LIB/.registry/.channel." . $channel . "/" .
>             strtolower($pkg) . ".reg\n";
>

I haven't tested the above with a bunch of other pear packages,
so if someone could check that, that would be great.  But, as you
can see, it digs the channel out of the package.xml file.  I'm
still stuck manually doing a "pear channel-discover foo".

- From a, b, and c above, I don't think c makes sense.  The
question then is, from a pkgsrc paradigm perspective, does it
make more sense to extend pear.mk or to add meta-packages?  The
advantage to doing the latter is that it could take advantage of
the PLIST magic for handling conditional deletion of files (if
multiple packages are using them); the disadvantage is that it's
providing only a minimal amount of functionality, and may end up
adding many packages (there are currently a dozen channels listed
at http://pear.php.net/channels/ and I only expect that list to
go).  Like I said before, I'm willing to work on this -- but, at
this point, I'd like some guidance from the team before I go down
the wrong path.

Cheers,
Chris

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

iD8DBQFGgnDfP65RBOOHTzERAsq1AKCqtW+oZCp32c3Vv4eqfFvtI0yemQCgyuPE
UNT1VpIVwyL6y1FsrUsTd7A=
=YoKi
-----END PGP SIGNATURE-----