Definitely more modularity, but that doesn't mean that we expose all 
of the modularity to the installing user. :) But I'm convinced for now.

We did exactly this in the past, and it caused more problems than it 
solved in the end, mostly because of always being outdated, see my 
earlier comment.

I guess there are two very different perspectives here: the viewpoint 
of a distribution and the viewpoint of the user installing horde on a 
webserver without support of package management from a distribution.
From the viewpoint of the distribution this is definitely the job of 
the package manager. Bundled PEAR packages only cause pain from that 
point of view because the least one has to do is to remove them. But I 
experience plenty of additional problems with bundled PEAR packages 
when packaging stuff for Gentoo. On the other hand this was often just 
caused by lazy devs and that wouldn't happen with Horde.
As bundled packages may be helpful for users without support of a fine 
distro I wonder if it wouldn't be possible to find a compromise and 
simply  add a separate bundle tar.gz bundle of suggested PEAR 
packages. This way people might decide if they'd like to use it or not.

True, though this is the distribution's problem, not our.
I guess this has been discussed back and forth in many projects that 
use PEAR packages. I sometimes get fed up with BC breaking stuff in 
PEAR too. But the counter argument is, that PEAR packages are usually 
updated much more frequently than Horde, so people won't get updates 
or even security fixes.
If they have to install separate tarballs anyway, it doesn't add too 
much work to install PEAR packages IMO. Especially since the PEAR 
installer has much matured in the past. And I thought we would rather 
try to achieve more modularity, not less.

PEAR is already tricky for distributions, since you don't get the same 
thing installing distro packages vs. using the PEAR command.



And we've been burned multiple times by PEAR changes (DB.php quote(), 
etc.) when people upgrade. Distributing the supported package version 
with Horde could eliminate a lot of that.



Unless we offer bundles with every single app combination or at least 
base app package (chora/whups/etc., hermes/minerva/etc.), I think a 
lot of people will use the tarballs that don't need special 
flexibility. And if they want to use their own PEAR libs they can 
adjust the include_path accordingly.

I'm against it, because people still using separate installs do so 
because they want full control about all components. Bundled PEAR 
packages are not easily upgradeable, and might already be on the 
system, causing redundancy.

This would also turn into a maintenance nightmare for distributions, 
that definitely don't want duplicate code in their packages.

I think this would cause more trouble than it solves, if people want 
convenience, they can install the bundles.

Since we already bundle the necessary framework libraries with Horde 
tarball releases, how about doing the PEAR libs too?