Re: Bootstrapping PEAR for distros

From: Date: Fri, 14 Apr 2006 19:44:32 +0000
Subject: Re: Bootstrapping PEAR for distros
References: 1 2 3 4 5  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-42232@lists.php.net to get a copy of this message
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. > > Maybe I'll try to provide you with some life example. We have a tool > called poldek, which is a great command line interface to RPM. Think of > it as an equivelant of apt-get or yum. > > So we have User that uses PLD and poldek. He/she wants to install > eventum, which we have packaged. However, eventum requires a set of PEAR > packages in order to work. So we put them into eventum's Requires: > field. In order to satisfy these dependencies, poldek fetches these > packages (which we have in RPMs too) and installs them in one batch. > > If we wanted to use PEAR's internal dependencies, which in fact means we > would resign from creating RPM packages for those, we would have to > provide some other mechanism to install them. That way or another, we > would have to package at least PEAR's pear CLI and put something like > 'pear install XXX' in eventum's post installation scripts. > > But as I wrote in my previous mail, there's a catch - we cannot asume we > have a network connection. So, maybe include *.tgz in RPMs and put > 'pear install XXX.tgz' in eventum's post installation scripts? But... > what for? We could as well create RPM packages for those. > > And that's what we actually do. > > 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). > > > > 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. -- Justin Patrin

« previous php.pear.dev (#42232) next »