[289] in athena10
Pine and Athena 10
daemon@ATHENA.MIT.EDU (ghudson@MIT.EDU)
Tue Jul 1 12:41:47 2008
Date: Tue, 1 Jul 2008 12:41:03 -0400 (EDT)
From: ghudson@MIT.EDU
Message-Id: <200807011641.m61Gf3HN022569@outgoing.mit.edu>
To: athena10@mit.edu
Right now I think Debathena has a Pine package build from a copy of
Athena 9.4's third/pine tree, and Athena 10 has a placeholder equivs
package. Before the fall preview release, I'd like to have a
debathenify-alpine script and a debathena-alpine-config package. Here
are my initial notes; feedback before I begin the grunt work is
welcome.
I'm aware of the alpine locker and will steal from it liberally. I
love the breakdown into individual patches.
I previously reviewed the source changes we made to Pine in Athena 9.x
and categorized them as follows:
1. Hesiod support
2. krb4 IMAP support
3. kpop support
4. Avoid filtering out non-primary inboxes
5. Use custom mailcap and mime.types files
6. Ensure mail directories are private
7. Custom pine.conf
- Set user-domain to mit.edu
- Set inbox-path to {mit.edu/hesiod/imap}INBOX
- Turn on mail check cue feature
- Turn on feature to quote lines starting with "From" when saving
- Enable the display-full-headers command
- Set the URL viewer to /usr/athena/bin/htmlview
- Set the bug, suggestion, and support email addresses
- Set up folder collections for IMAP, old MH mail, and old Pine mail
- Use sendmail to transmit mail
Hesiod support could be done in a wrapper script, but krb4 IMAP
support will require code changes, so we may as well do Hesiod support
the easy way for now.
I don't care about kpop support; it's a holdover from the old SIPB
Pine and I don't think it gets used. On the other hand, it's not hard
to add (the alpine locker has a patch for it) so if anyone knows of a
reason for me to care about it, I can throw it in for now.
I don't know if (4) is still necessary in alpine. I don't see a patch
for it in the alpine locker. I will have to look at the relevant part
of the alpine code. Even if it is still an issue in the alpine code
base, it's perhaps less important since we're no longer actively
conducting a transition from nmh and SIPB Pine mail stores to IMAP
stores.
Generally speaking, the native OS can be trusted to handle attachments
fairly well, so I'm going to ignore (5) until we identify an issue
under the new OS and code base.
(6) is best handled by a wrapper script, although I may still do it in
the code if there is no other reason to have a wrapper script.
One last concern. Evan Broder wrote in a piece of mail to
sipb@mit.edu:
> I don't know what Anders has done, but he's got patches against
> Alpine running in the locker. If I remember correctly, they're
> uncommitted due to some combination of "real people don't care about
> krb4 anymore" and "you can't make it work without completely tearing
> out krb5".
I obviously don't want to tear out krb5 support. I don't see any
indication that krb5 support is removed in the locker patches; was
this just a misrecollection on Evan's part or is there a gotcha?
