[horde] Distribution packaging of composer based applications was: Re: Finished importing horde FW_6 to packagist.org / composer / compatibility with newer PHP versions

[Lang, Ralf]

Hi Thierry,

> Great!
>
> Also, would it be possible to provide a way to install Horde and its
> applications without composer?
>
> As a packager, it seems that composer is not ideal: e.g. see this
> message:
> <https://www.mail-archive.com/ports@freebsd.org/msg04879.html>
> (and the others in this thread).
>
> Previously Horde 5.2.23 (with IMP 6.2.27 and the others) has been
> packaged for FreeBSD: see
> <https://www.freshports.org/www/horde-base>.
>
> It has been removed with PHP-7.4, and I’d like to resurrect it, but it
> appears to be difficult with Composer, and the same thing surely
> concerns many Linux distributions.
>
> Best regards.

TL;DR - It's complicated but there's probably a way to get what you 
want. I am just not sure if it's worth the effort and if the 
distribution will like it.

Nowadays, I'd rather put this type of software into a (set of) OCI 
container orchestration, i.e. docker-compose or kubernetes. This is what 
I did two years ago maintaina/deployments: Various premade deployments 
to develop or run Horde environments (github.com) 
<https://github.com/maintaina/deployments> and once Horde 6 is released 
and in good shape, some kind of turnkey solution is probably something I 
want to get back at.

Horde Groupware won't just run by installing a few packages. You need a 
mail server - not necessarily run by yourself though. You need a 
database, probably you want a key/value store (redis, memcache) and an 
LDAP or ActiveDirectory as a user management.

Why is it complicated?

In the past I was a distribution packager myself doing RPMs for Horde 3/4/5.
Back then PEAR was the default php package manager and PEAR's default 
behaviour was to install all packages into a system wide tree.

This plays nice with distribution packaging where each item has one 
defined place in the file tree. Most distribution mechanisms internally 
even leveraged PEAR, minus the downloading aspect.

Some distributions took this up to eleven and mangled Horde's structure 
into FHS compatible folders with some patches, i.e. moving config files 
to /etc/.

But this is fundamentally not what composer does. It bundles a separate 
dependency tree for every app. Dependencies may be duplicated between 
apps and they may have different versions for different apps on the same 
system.

Now enter Horde's own plugin mechanism into the picture. Traditionally, 
Horde 5 put applications into a folder inside the horde base app. With 
composer, libraries, apps and horde base all live in the vendor/horde 
folder and are glued together by some configs and links in the root 
project. That creates a lot of complexity. Most modern web development 
package managers follow the same principle. npm (javascript), ruby, even 
python's pip like building separate, duplicate dependency trees for apps.

Distributions usually don't want rpm or deb packages or bsd ports to be 
big balls of mud with their own dependencies all rolled into one. They 
often want dependencies split into separate packages, docs and 
translations split into separate packages, development-related files 
split off the actual production app. Dealing with that consumes much 
time, but if you are up to it, some ideas.

- You need to compile an autoloader which reacts on what is there and 
what is not there. One could probably pre-compile an autoload.php for 
each package and federate them into some app specific autoload.php so 
everything is available. You could also simply let composer generate the 
autoloader if you make it use local sources.
- You could probably roll most of the libraries into a reasonable blob 
"framework" and externalize those dependencies which come from other 
vendors (sabre/dav, etc). This would make you maintain 10-20 individual 
packages rather than 180.
- Or you could roll a whole "groupware" setup into one package. I can 
support with that. However, most distributions absolute don't want this 
type of package.

Mr Leidinger made some good points about the intricacies of all this. 
However, the discussion in the other ML got some facts wrong.
Composer can be made to work with pre-fetched artifacts and local 
repositories. You can absolutely make composer run without accessing a 
satis or packagist repository.