Re: Bootstrapping PEAR for distros

On 4/14/06, Adam Gołębiowski <adamg@biomerieux.pl> wrote: > On Fri, Apr 14, 2006 at 12:44:32PM -0700, Justin Patrin wrote: > > On 4/14/06, Adam Gołębiowski <adamg@biomerieux.pl> wrote: > > > On Fri, Apr 14, 2006 at 11:05:40AM -0700, Justin Patrin wrote: > > > > On 4/14/06, Adam Gołębiowski <adamg@biomerieux.pl> wrote: > > > > > On Thu, Apr 13, 2006 at 10:18:17AM -0700, Justin Patrin wrote: > > > > > > 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. > > > > > > > > > > The reason that we (PLD) repackage PEAR packages and put them into RPMs > > > > > is that we want to benefit from RPM's dependecies. For example, if one > > > > > of our users decides to install eventum, PEAR's Benchmark, DB, Date > > > > > and > > > > > other packages are also installed. > > > > > > > > > > This is something that can't be easily done with PEAR's > > > > > installer, and > > > > > we can not assume that user has access to the http. > > > > > > > > > > > > > Ummm...excuse me? PEAR handles dependencies exceddingly well. Of > > > > course, it can't download and install PHP extensions for you, but > > > > that's not too hard to do. You could even add an extension to PEAR to > > > > install these extensions via RPM. > > > > > > I don't say that PEAR doesn't handle dependencies well. I am using it > > > for some of my projects, and they work well, but they don't necessary > > > fit into Distribution's point of view of package management. > > > > I do understand the idea of doing all of the installation via one > > package manager. The problem, of course, is that PEAR has the > > infrastructure for package management itself and adding another layer > > causes extra work for the distributions' packagers. In addition, if > > the PEAR installer isn't used we can have a hard time supporting > > people since the PEAR installer is assumed to be used (for various > > reasons, not the least of which is putting files in the right place, > > but also for pre/post installation scripts and replacements in code). > > And on top of *that* when we release a package the distribution then > > needs to repackage the new version to let people update. This tends to > > happen not at all of very very slowly. > > On the other hand user has to remember on doing 'pear update-channels' > and 'pear upgrade-all' from time to time, aside from typical RPM > packages updates. > > And from what I see, if any problems occur, they are reported either on > our mailing lists, or through our bug tracker (though the latter is not > as popular bug-reporting tool as in PHP). > > > > > If you have some ideas on how to improve the process, we're open for > > > suggestions. > > > > Including a tgz in the script and running the PEAR installer would be > > IMHO a far better solution. PEAR knows how to install its packages and > > can run all of the checks and scripts and replacements correctly. It > > should be fairly easy to handle error conditions, at least in the case > > where you should error out and let the user know about an error. The > > PEAR command *should* be emitting correct exit codes (Greg, please > > correct me if I'm wrong). > > Include in which script? Eventum's? And all of the other packages too? > Technically it is possible that we include PEAR's *.tgz archive in RPM > package and do a 'pear install foo.tgz' in post-installation scripts. > > However, that would mean that a popular PEAR package would be duplicated > across multiple PHP projects we RPMized for our users. For a waste of > space on ftp server and mirrors (not a big one, but still) all we > would actually get is a PEAR's support for dependencies? > > I guess that's not a good deal, and it's better for us to stick with RPM > deps. After all, we do make use of PEAR's pear CLI in RPM build phase. That's not what I meant. What I meant is to make the RPMs for the PEAR packages include the tarball and use the pear installer. > > > > > > PS: In case this mail doesn't hit pear-dev, anyone knows whom can I > > > > > contact to solve this issue? I keep getting mails but can't post to > > > > > the > > > > > list. listmaster@, postmaster@ or is there any other address I could > > > > > write to? > > > > > > > > Seems to be working fine. > > > > > > No, it's not :( It didn't hit the pear-dev - I can't see it on > > > http://news.php.net/pear.dev, I didn't receive > > > this message either. > > > I dunno why is it so. > > > > > > > Yes, it is fine. I'm on the pear-dev list and I got your message. I'm > > definately not any of the other people listed so it must have made it > > to pear-dev. > > That's odd, cause I didn't receive that (my) message (and I should as I > am subscribed to pear-dev) and can't see it through > http://news.php.net/pear.dev > -- Justin Patrin