> * Fewer packages to maintain. > I would add: > * a single package for accessing all evolution data.
I really favour the "camel in e-d-s" option, because it makes e-d-s the one-stop-shop for accessing Evolution data. I think that is actually a convenience for developers, not a hindrance. > Well, I guess this is really about adding a lot of deps for Camel users > vs. adding one dep for e-d-s users. The decision will have to be based > on, for each group (camel, e-d-s), the number of persons expected to be > in that group multiplied by the amount of suffering the extra deps will > cause. I don't think adding dependencies necessarily causes "suffering". Being able to use e-d-s for all your Evo development needs is convenient. On a modern distro, just install e-d-s and e-d-s-dev, have the dependencies resolved for you, and you're done. That's the picture for people developing add-ins outside of Evolution and e-d-s proper. The developers of e-d-s and Evo themselves already have to endure pretty complicated build procedures, and I doubt this will make it much worse, though I could be wrong. I've been building Evo 1.5 snapshots and, while they're not difficult to build, you do need to take care to build things in the right order already. Requiring that camel gets built before e-d-s seems like it won't make things too much more complicated, but I don't do it multiple times per day :) Have fun, Peter _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
