[1661] in athena10
Re: Changes to debathena-alpine-config
daemon@ATHENA.MIT.EDU (Evan Broder)
Sat Mar 14 10:12:07 2009
Message-ID: <49BBBAEB.2000901@mit.edu>
Date: Sat, 14 Mar 2009 10:10:51 -0400
From: Evan Broder <broder@MIT.EDU>
MIME-Version: 1.0
To: Evan Broder <broder@mit.edu>
CC: debathena@mit.edu
In-Reply-To: <49BB40EA.5000304@mit.edu>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Oh, wow - the user experience on Hardy is worse than I was hoping.
aptitude is much happier to remove debathena-alpine-config (now that
it's a recommendation) than to downgrade alpine to 1.0.
It also prompts you about having to freeze alpine lower than the highest
available version in order to satisfy the debathena-alpine dependency
after you've done so (i.e. you'll get prompted every time you do a
dist-upgrade).
I'm not really sure if there's a way make the user experience better,
but I'm more skeptical of this change than I was last night. If we think
there's a chance that krb5 IMAP will be deployed soon, I'm more inclined
to just leave the dependencies as they are.
- Evan
Evan Broder wrote:
> Tim asked me to send mail explaining the zephyr discussion about
> alpine-config today, so here it is:
>
> The big change made to debathena-alpine-config today was changing the
> package from
>
> Depends: alpine
> Recommends: debathena-alpine
>
> to
>
> Depends: debathena-alpine
>
> This was coincident to changing debathena-clients from depending on
> debathena-alpine-config to recommending it (so that debathena-clients
> remains installable without the debathena-system component enabled)
>
> This change should affect Debathena Hardy more than any other release.
> Ubuntu included alpine 1.0 in hardy, but put alpine 2.00 in
> hardy-backports. Since we debathenify without backports, we debathenify
> 1.0. 2.00 wins against 1.0 in the version number battle, meaning that a
> user with hardy-backports enabled will get a non-debathenified alpine
> instead of ours.
>
> Since debathena-alpine-config sets inbox-path and folder-collections to
> values involving hesiod, the pine.conf provided by
> debathena-alpine-config did not work against the alpine in
> hardy-backports (you'd get a mysterious error to the effect of
> /mit/broder/Public/hardy-alpine.png). Given that we require the patched
> behavior, the dependencies seem clearly wrong as they were.
>
> For some context, we're hoping that network will soon switch the PO
> servers to accepting GSSAPI authentication on *.mail.mit.edu. Once this
> happens, we no longer need either the Hesiod patch or the krb4 patch to
> alpine, and the homedir permissions patch can be replaced by a wrapper
> script. In other words, alpine would no longer need to be debathenified.
>
> One alternative to what I implemented would have been to change the
> debathenificator to debathenify alpine 2.00 for Hardy. However, we would
> then be eliminating choice because our alpine 2.00 would always win
> against the alpine 1.0 in hardy for users who didn't want to turn on
> backports.
>
> This way, users with -backports turned on will be forced down to 1.0 for
> the time being, but when we can lift the requirement specifically on a
> debathenified alpine, they'll be able to upgrade back to 2.00. It
> temporarily sucks, but is better in the long term.
>
> I also reverted geofft's commit about aspell, in favor of handling that
> upstream (LP #340993 for Jaunty). I suspect we wouldn't have too much
> trouble pushing for an SRU for Hardy and Intrepid, and whatever Debian's
> post-release fix process is for Lenny, so we should go ahead and try.
>
> I also switched to using DEB_TRANSFORM_FILES instead of
> DEB_DIVERT_FILES. Theoretically, this should be a purely aesthetic
> change to the source package, but I'm not sure I trust my Perl enough to
> believe that.
>
> I'll be leaving this package in -proposed for feedback until Wednesday
> or so, at which point I'll move it into production.
>
> - Evan
>
>
