[Kolab-devel] gunnar: server/kolab-webclient - New directory

[Gunnar Wrobel]

Quoting "Thomas Arendsen Hein" <thomas at intevation.de>:

> Hallo Gunnar!
>
> * cvs at kolab.org <cvs at kolab.org> [20080811 11:35]:
>> Author: gunnar
>>
>> Update of /kolabrepository/server/kolab-webclient
>> In directory doto:/tmp/cvs-serv4012/kolab-webclient
>>
>> Log Message:
>> Directory /kolabrepository/server/kolab-webclient added to the repository
>
> Why did you add that?

I'm currently preparing the next round of horde updates to move  
towards Kolab Server 2.2.1.

I did ponder the best way of maintaining the Kolab patch queue for  
Horde release packages last week. I did initially add the Horde  
packages as splitted packages under "/server/horde".

In principle I still believe this is the right way of doing things.  
One package, one spec file and a decent definition of dependencies.

PHP applications have had a history of neglecting the common (and  
sane) concept of programming libraries. Instead many apps simply  
"bundle" the required libraries to be installed into the webservers  
document root. I think we know the drawbacks of such an approach  
pretty well (security, maintainability).

Horde has a splitted approach of releasing packages which is not  
totally consistent. All the applications are being released as single  
packages. But the framework packages are all PEAR packages that should  
be released as single modules or packages, too. Instead they are  
bundled with the base horde-package and the user is expected to  
install the libraries into the web root.

I did correct that for the package definitions in "/server/horde" and  
this is why we have "/server/horde/horde-framework-kolab" and  
"/server/horde/horde/".

But Horde also distributes larger monolithic packages that combine all  
the common applications such as imp, kronolith, turba, nag and so on.  
In addition these packages contain all required PEAR packages to run  
Horde. I guess many users prefer these types of packages because they  
just untar them into the document root of the web server and are up  
and running.

While this is not really the best thing to do security-wise and  
restricts the user as well as maintenance, I'm still in favor of  
moving the OpenPKG packages (as well as the Gentoo packages btw - and  
it does hurt me more there) to the monolithic horde release.

This has one significant advantage over the splitted packages: We can  
provide a single kolab-specific patch that can be applied to the  
horde-webmail package instead of having more than ten different  
patches for the different applications.

And since I trust Horde to handle security well enough I think the  
single monolithic approach is the easier approach at the moment. It  
hopefully makes it clearer what we are doing there.

Of course the single patches are still available at my patch queue  
(http://hg.pardus.de/cgi-bin/hg.cgi/horde/HORDE/file/tip/series - the  
release patches are guarded with "release"). So I don't think we loose  
anything.

Do people agree?

Cheers,

Gunnar

>
> Thomas
>
> --
> thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key:  
> 0x5816791A
> Intevation GmbH, Osnabrueck - Register: Amtsgericht Osnabrueck, HR B 18998
> Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-keys
Size: 2803 bytes
Desc: ?ffentlicher PGP-Schl?ssel
URL: <http://lists.kolab.org/pipermail/devel/attachments/20080811/f822b4e6/attachment.bin>