dev-php/horde or web-apps/horde

[vovan]

There's dev-php/horde in the kolab2 overlay which is the same as web-apps/horde + kolab-horde-framework-iCalendar patch. Is it possible using patching web-apps/horde for kolab horde integration or should we use dev-php/horde? In the last scenario I would suggest adding blocking of web-apps/horde to dev-php/horde ebuild. I don't think having both packages installed at the same time is a good idea. 

[Gunnar Wrobel]

Hi Vovan!

The dev-php/horde in the overlay is not quite the same as the www-apps/horde ebuild. Besides the patch that you mentioned the second larger difference is the install location. The dev-php/horde ebuild inherits the php-lib-r1 eclass instead of the webapp.eclass. This means that the horde code is treated as a library (which it actually is) and not as a web application as the standard horde ebuild does it.

This is also the reason why both ebuilds do not block each other. You can install horde in /usr/share/php as a library and install it at the same time as a web application in your virtual hosts.

On the other hand you are right and it is somehow weird to install the same code in several locations. But Kolab requires the Horde code as a library and I think that the only alternative I see is even worse.

One could use the standard horde ebuild, add the patch as dependant on the "kolab" use flag. In that case the horde code would end up as a webapp under /usr/share/webapps/horde/VERSION/...  Having the VERSION in there is a problem if I depend on the code as a library. So the user would have to use webapp-config in order to install the horde library into a defined vhosts (probably /var/www/kolab/htdocs/horde then). But this also feels wrong.

Horde is somewhat problematic since it's both library and web application. The current ebuilds in portage have also been criticised a few times and not everybody is happy with them.

Hope that explains the weird situation.

Cheers

Gunnar

[vovan]

The provided explanation is clear, so I think it's the best using the ebuild from kolab's overlay and remove the original one. I'll try to do that soon and post results here.

[Gunnar Wrobel]

I do intent to provide specific horde ebuilds for kolab at a later point. Right now there are still too many bugs and problems when integrating these two.

But I guess that this would also result in having horde installed twice. Once as a library in /usr/share/php, once as a webapp that get's installed into /usr/share/webapps and that will be transferred with webapp-config to /var/www/kolab/htdocs/horde.

So I don't think that you really need to remove the current horde. They should not bite each other

[timmy]

I'm still running the standard portage versions of the Horde apps, but I'd like to start using the Kolab overlay versions.

Reading the ebuilds, it looks like they get installed directly in /var/www/kolab/htdocs/horde. Is there any reason why they can't use webapp-config and the vhost USE flag, like the standard versions?

Cheers,
Tim

[Gunnar Wrobel]

The main reason for this is that the kolab system allows to automatically configure horde this way. There are templates in /etc/kolab/templates that will get written into /var/www/kolab/htdocs/horde and thus automatically tweak horde to work with your kolab system.

It would also be possible to use ebuilds that use webapp-config but I figured most setups would only install horde once. So I did choose the other option.