Re: Bootstrapping PEAR for distros

Justin Patrin wrote:

Bootstrap PEAR with go-pear. That's how it's done. The phar is convenient, but you don't need to use it, you can just use go-pear.org. If you use the normal go-pear you should get the newest packages.

go-pear seems to be a bit too networky and interactive for this purpose. With RPM packaging, a key tenet is that you have a set of static, already-downloaded packages together with a "spec" file, and together they form a *complete* set of sources that are used to build a finished a) package and b) source package. The spec file is not supposed to download stuff from external sources; this compromises the integrity of the process not least because a) you can't mark a point in time where you can verify the complete set of sources and say "these are all the real deal" and b) the source package won't be rebuildable offline (it should be completely self-contained). Now, maybe we could tweak go-pear to work entirely offline and non-interactively, so that might be an option. (Lots of hacking means we end up back where we started though). I don't think either myself or Joe have investigated that; I certainly dismissed go-pear initially for the reasons above. However, thanks for the suggestion.

It's a bit hackish in the first place for distros to be repackaging PEAR packages and installing them with its installer since PEAR has its own installer. The correct way to upgrade PEAR packages is to use the PEAR installer directly.

I disagree. Whilst there's nothing wrong with the PEAR installer, distributions (or application hosting environments) should be self-consistent, and this means using a consistent packaging system across all software. This has many advantages, not least dependency resolution across the whole system. A Fedora user should be able to do "yum install foo-web-app" and get a working foo-web-app, no matter whether it requires PEAR, PEAR::Foo_Bar, some-binary-package or all of those. This is even more important in automated hosting/deployment environments where software updates may be pushed to large numbers of systems via yum/apt/smart/whatever auto-updates. Having to incorporate scripts that run "pear install Foo_Bar" and do all the associated error handling into that process just adds unnecessary complication. Just because PEAR has its own installer doesn't exempt it (and PEAR modules) from being packaged up like every other app on the system. Of course, there's nothing to stop a user installing the base package and then using PEAR's own installer to maintain things although they of course lose some of the benefits of the native package management then, as the native package manager won't know about the new packages that have been installed. Also note that most external RPM etc. packages (including those generated by PEAR_Command_Packaging) try hard to "play nice" with the PEAR installer, by registering and deregistering packages with the PEAR depdb as they are installed/removed. Thanks for the comments, though. Tim