Re: possible solution to bundles vs. bundles [sleeping does help!]

Alan Knowles wrote:

A little off topic, to be honest, I'm not 100% sure, I have a real need the bundling stuff, but the making deps work with fixed urls would help no end: eg. <dep type="pkg" rel="has" name="Foo" src="http://www.akbkhome.com/.......mypackage.tgz"/> This may remove the necessity for pearballs..., as I'm unlikely to set up a channel server just for a few packages.

I'm planning to set up an xml backend for PEAR_Server that will allow simple channels with only a few packages to still use the server without requiring massive database setup, only a few pre-built xml-rpc response files that the xmlrpc.php script can dumbly serve on receiving requests. I suspect that most channels will not be serving nearly as many packages as PEAR. I'm also considering defining a fake channel for the dependencies that use a uri tag, so that they can't be used to surreptitiously "upgrade" an existing package into a trojan horse. $ pear install UsesFoo.tgz downloading Foo (from uri http://www.akbkhome.com/........mypackage.tgz)....done install of __custom::Foo 1.2.4 OK $ pear remote-list __custom Cannot remote-list from virtual channel __custom $ pear list __custom (VIRTUAL) CHANNEL __CUSTOM PACKAGES: =================================

NAME        VERSION

-------------------

Foo         1.2.4

Something along those lines. Alternate names are __private, __uri, or anybody else's better ideas. Greg P.S. I'm probably going to rename PEAR_Server to Chiara_Server, it seems to make more sense in the long run. Chiara_PEAR_Server is too long for my feeble typing fingers and impatience.