Re: Observations on setting up a PEAR channel

Tim Jackson wrote: > Enough about the overview, let's consider a couple of noteworthy things > that make RPM/yum different to PEAR. 0. PEAR has automatic channel server resolution Unlike RPMs, where the server location is not defined in the spec file, if you don't already know where to find a package, you have to manually add the server to your list of repositories. RPM puts the burden of locating servers on the user. This works great when you only want to add 1 or 2 packages at a time, but from personal experience, it is a royal pain in the ass if you want to install non-standard RPMs. In fact, I have the same issue with all OS-based distribution systems. 0.5. That's another difference: RPM was designed to allow maintaining remote updates of an OS, where the need for cross-server dependencies is non-existent. If you have an RPM named "Log" from one server, RPM assumes that an RPM named "Log" from another server is in fact the same, and will treat them as identical. This can be extremely dangerous in PHP, where common tasks implemented in userland always have the same name. Without defining the source of the package in the meta-data (package.xml) we run the risk of allowing people to destroy their installation by accidentally "upgrading" to a package from another channel. More sinisterly, if a malicious user were to clone the PEAR package, for instance, and make it a hidden dependency in their own package, it would be possible to "upgrade" the PEAR installer itself and install spyware without the enduser ever knowing. This is probably the main reason that RPM requires the end user to manually set up servers, as it requires a tradeoff of convenience for security. PEAR puts the onus of convenience on the package distributor to a certain extent, but provides extra security to ensure that malicious packages are not possible. A lot of thought went into how to do this properly, and because of the initial decision to allow auto-discovery of channel services, meta-data cannot be separated from the package without introducing tremendous risk. However, the channel.xml specification fully supports mirroring, which is a simple way to move packages to another server without having to change anything. The mirrors are defined at the source channel, again for security reasons. > d) It makes the initial packaging process simpler; a package can be > built NOW and subsequently incorporated into a/some channel(s), unlike > with PEAR where a channel must be set up and 'channel-discover'd before > a package can even be built for that channel. This makes the barrier to > entry very high for someone, especially since Chiara_PEAR_Server can be > tricky to get up and running. This is not true - if you take the channel.xml from http://pear.php.net/channel.xml and modify it to define a new channel, you can pear channel-add channel.xml and immediately install/upgrade packages from that channel. > Now, just out of interest, I started to have a little look at what the > technical issues might be in moving the channel metadata from originator > to end-user: The installer would have to be completely redesigned, and frankly the better solution is to make it easier to set up channel information. It is quite possible to create a channel server that does not require a database, all we would need to do is generate REST from the release archives. This has been on the distant TODO list in my mind, and would be a wonderful PEAR package as a channel server for "lite" channels. > 2. Managing your own channel It might be helpful to understand the history behind channels. Originally, pear.php.net was an XML-RPC-based service, and development versions of PEAR 1.4.0 right up to 1.4.0a12 (http://pear.php.net/package/PEAR/download/1.4.0a12) used XML-RPC. PEAR_Server was designed and released prior to 1.4.0a12, and so like pear.php.net, REST was an addon after the fact. At a certain point, I found my energy to redesign was lagging :). In addition, I suspected that adoption of Chiara_PEAR_Server was not high enough to really see the issues, and that I should wait to redesign. Now that people are really starting to use it, I think the time is ripe for a revisit and an official channel server "lite" distributed through pear.php.net. > So, to summarise, the PEAR Installer and RPM+yum fulfil very similar > roles in their respective areas. However, as an observer, I had to jump > through many more hoops to get up and running with a PEAR channel. None > of them were pointless, or useless, but it seems to be me that it would > be nice to lower the barrier to entry for simple cases. I agree, it is very interesting to see the barriers from others' perspectives, thanks for this interesting and provocative post. Greg