On Wed, 2006-07-12 at 17:39 +0200, Philip Van Hoof wrote:
> > What advantages does being able to dist camel on its own have, over
> > simply packaging it in a separate package like OpenEmbedded and Debian
> > do:
> It's cleaner in my opinion :-), and I can more easily create a tar.gz
> release.

Cleaner for what reasons?

> > Before you can dist it as a separate package you'll need to remove the
> > use of libedataserver.  That might not be possible or realistic, so I'd
> > attempt that first.
> Or do all the libraries in evolution-data-server with their own
> configure.ac?

So you are proposing the following library packages:


And then binary packages for the Groupwise helpers, the Exchange
helpers, and the server binaries themselves.

I'm also not sure where the backends would go in this scheme.

No, I don't think that is a good idea either.

> > If you find large bits of code that are only used in camel and are
> > currently in libedataserver, I'd propose moving them into camel:
> > libedataserver could do with slimming down.
> For example EMsgPort, is that used by something else but Camel?

By the magic of grep, libedataserverui/e-passwords.c uses e-msgport.c.

Ross Burton                                 mail: [EMAIL PROTECTED]
                                          jabber: [EMAIL PROTECTED]
                                     www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF

Attachment: signature.asc
Description: This is a digitally signed message part

Evolution-hackers mailing list

Reply via email to