Re: [Evolution-hackers] camel->split in? eds or not

>  * 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,


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]