[323] in athena10
Evolution stuff
daemon@ATHENA.MIT.EDU (ghudson@MIT.EDU)
Tue Jul 22 11:46:40 2008
Date: Tue, 22 Jul 2008 11:45:55 -0400 (EDT)
From: ghudson@MIT.EDU
Message-Id: <200807221545.m6MFjtUF017059@outgoing.mit.edu>
To: athena10@mit.edu
Right now the Evolution wrapper isn't quite right. It has a recommend
clause which will pull in the debathenified version of one of the many
evolution-data-server packages, but not the right one. (The right one
is named libcamel1.2-11, but presumably the numeric part of that
package name might change semi-frequently.)
Also, I'm concerned about the user experience if evolution-data-server
is upgraded and autodebathenify doesn't run in time. I'm not sure
whether aptitude will hold back libcamel purely on the basis of a
Recommends clause.
I have three basic ideas for improving the situation:
1. Make our libcamel package provide something like
"debathena-evolution-krb4" which the wrapper can recommend. This
is the minimal fix to the first problem.
2. Remove all of the binary packages from the control file except
for the libcamel one, out of a sense of cleanliness. I'm not
sure if this is actually cleaner, though.
3. Do (2), but also rename the package to something like
debathena-libcamel-krb4 and put it in the debathena component
instead of debathena-system. The evolution wrapper could then
depend on this package instead of merely recommending it. The
new package would Provide and Replace and Conflict with
libcamel1.2-11, so I'm not sure if it would really be morally
different from being named libcamel1.2-11. (The same question
applies to debathena-lprng, which Replaces and Conflicts with
lprng.)
The more general issue here is that it is not always easy to make
Debathena installable without the debathena-system component without
compromising the user experience in other ways.
I'll start with (1) since it's an obvious fix and is easy to do.
