Re: Bootstrapping PEAR for distros

On 4/14/06, Tim Jackson <lists@timj.co.uk> wrote: > 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. go-pear *can* work offline, IIRC. I think that you can pre-download the packages and have it use those instead of going online. This way you can specify what versions you want to use and not go online. I believe that go-pear supports a non-interactive mode, but I could be mistaken. > > > 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. > I have many things I would say here, but if PEAR_Command_Packaging is doing the RPM creation then, as long as that code is written well, things should be ok. Basically what I'm worried about is converting depdendencies to new formats (esp. if by hand) and installer tasks. PEAR has built-in support for doing pre/post install tasks as well as replacements of special tokens in source files. If these steps are skipped in your non-PEAR installer then things are going to break. > Thanks for the comments, though. > -- Justin Patrin