Open Xchange for FC5 with GCJ 4.1

[David Hollis]

On Mon, 2006-02-20 at 00:33 +0100, Erwin Rol wrote:

> Of course not everything works, but database access seems to work now
> with postgresql 8.1 (both server and jdbc). Webmail also seems to be
> able to read mail. And I can login, so Ldap also kind of works. I think
> ldap addressbook is still a problem, but that is because the ldap part
> is a serious hack, the imap stuff also has some hanks.
> 
> Since I have a busy week coming up I will continue with the development
> next weekend, I hope some ppl could play around with it in the meanwhile
> and report all problems to me, so I can fix them next weekend.

Some initial thoughts while looking through the spec file:

It would be nice to be able to keep the html docs out of /var/www/html.
It may be a bit debatable as to where the best location would be,
possibly /var/www/open-xchange, /usr/share/open-xchange/.... or
something.  Then just add a open-xchange.conf to /etc/httpd/conf.d/ that
aliases the directory appropriately.  Knowing how OX is, that may not be
possible without totally dorking stuff up.

I really don't like having to have database names, passwords, LDAP dns
and such specified at build time, but I don't think OX gives any
alternatives.... sigh....

Javamail - couldn't you have the OX spec depend on javamail >= 1.3.0 and
have the ox_javamail.spec have a "Provides: javamail 1.3.0" or whatnot?
That would allow newer javamail rpms to replace the ox_javamail when the
time comes and everything can continue playing nice.


You really don't have to extract the WAR files during RPM build do you?
Can't you just plop the .war in the /var/lib/tomcat5/webapps dir and it
will take care of everything?  Though I suppose you lose the RPM owning
those files... hmm, I don't know enough about tomcat app deployment to
know which way is best.

The gcj.patch file seems to hard code some .jars that can be specfied
with configure.  This could bite you later.  It looks like that patch
tackles a bunch of different issues, so it would be best to split it
out.  A lot of things might be useful to send upstream, some may be
specific to getting the package to build with Fedora, etc.  Check out
the kernel RPMS for examples of breaking out patches.  As things get
merged upstream, become outdated, etc, it's very easy to remove them
from the spec.  You probably don't want to have to maintain a parallel
source tree to generate patches.


-- 
David Hollis <dhollis at davehollis.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060222/8ec94b46/attachment.sig>