Re: Re: Observations on setting up a PEAR channel

Greg Beaver wrote: First, thanks for your comments Greg. To reiterate again if it wasn't clear, I'm not criticising any past design decisions, just offering some (hopefully) constructive thoughts from a "third party" perspective. Incidentally, if there's any background docs I should be reading, please do point me in the right direction (similarly for references in the PEAR Installer Manifesto printed book, which I have read and has actually given me a very interesting introduction to much of the history which precedes where we find ourselves today).

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.

This is all true and a significant benefit of the way PEAR does things. Thanks for the reminder.

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.

I'm not sure that's quite right; we often have cross-server deps. They're just not explicitly defined as such and don't have auto-discovery. As you rightly point out (and I touched on in my previous comments), this has both up and down sides. The ability for a package (including a core package) to be "upgraded" across repositories is a side-effect of this, which can be exploited both usefully (where intended) and maliciously (if a repository is compromised). I think PEAR is very clever here and the namespace delimitation is a good thing; I was just pointing out some of the complications it causes from a new user point of view.

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.

Interesting point, although I wasn't specifically talking about mirrors, I was thinking in general where (let's say) a friend decides that he wants to rsync packages X, Y and Z (but not A, B and C) from my package repository, and import them into his (different) repository.

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.

Ah. Interesting to know.

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.

Excellent, that confirms what I thought then.

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.

Fantastic. If you or anyone else does make a start on this, please let me know - I would like to help. And when I get time, if nobody else is working on it, I may well kick it off myself. Tim