[horde] Installing and deploying Horde: PEAR vs. Git

[Ralf Lang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 14.10.2012 16:23, schrieb Andreas Rieger:
> Hi,
> 
> the docs mention PEAR as the recommended way to install Horde and
> the installation via Git is (only) explained in the context of
> development setups.
> 
> So I am wondering what has to be considered if we would use Git as
> the source for our production deployments? What are the main
> benefits of using PEAR? What are the drawbacks using Git?


> I am asking as the route via Git seems much more flexible. For
> example we customise some aspects of Horde for our setup (adjust 
> templates, add some extensions etc.). Right now there are a lot of 
> manual steps involved if a new version of Horde gets released.
> Tracking the Horde repository on Github in an 'upstream' branch and
> creating an 'integration' branch were we apply our customizations
> on top of it seems so much cleaner; especially as we could
> continuously pull in the latest changes and we'd still be able to
> quickly overview all our patches and adjustments and push new
> versions to our test and live server.


> So apart from the pros and cons of 'Git vs. PEAR' I am really
> interested to learn how others organize their Horde deployments.
> Especially how you deal with local adjustments and server specific
> settings and how you automate the process of rolling out new
> versions.

I have done both ways. When shipping a custom horde app as a platform
I needed some latest-greates master branch stuff and some custom fixes
which were not upstream ready. I packaged a git setup as an RPM
package. Drawback is you ship everything at once or need to manually
delete stuff during RPM generation. Customers clicking "update all
configs" including unreleased apps could easily break their setup
otherwise. For example, there are some chicken-egg issues once the
unreleased ansel version is active and no image driver is configured.
Big pro of this is separating touched code from distributed releases.
But if you run such a setup in cli mode, you may have to prepend some
include paths to assure the right library versions are run.

Normally I prefer separated components, one package a library or app
installed to system default locations. It helps administrators of
larger setups to look for pear stuff where pear stuff belongs etc.
It also helps because the correct library and tool versions are called
by default.

- -- 
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang at b1-systems.de

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlB+WD4ACgkQCs1dsHJ/X7DmxQCdH3VceVqxheUmvNTXjZpIjK8l
b4QAn0s43s3e72rKtYICHMHLSZtJGTsa
=Cgxj
-----END PGP SIGNATURE-----