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:
libedataserver
libedataserverui
libebook
libedata-book
libecal
libedata-cal
libgroupwise
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
--
Ross Burton mail: ross burtonini com
jabber: ross burtonini com
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