Ticket #74 (closed enhancement: fixed)
Upgrade nmh based on Debian's 1.3 package
Reported by: | andersk | Owned by: | mitchb |
---|---|---|---|
Priority: | blocker | Milestone: | Summer 2010 (Lucid Deploy) |
Component: | -- | Keywords: | |
Cc: | Fixed in version: | ||
Upstream bug: |
Description
The current debathena-nmh is based on the patched nmh 1.0 sources from Athena 9.4. We should figure out a minimal set of patches and apply them to Debian's nmh 1.2 package instead.
Change History
comment:2 Changed 15 years ago by mitchb
- Status changed from new to accepted
- Summary changed from Upgrade nmh based on Debian's 1.2 package to Upgrade nmh based on Debian's 1.3 package
I've done some significant analysis of Ubuntu's nmh-1.3 package and
the patches we had applied to nmh-1.0 in Athena 9, combined with a
look at what we'd need to do to take advantage of SASL support to
authenticate with GSSAPI and lose the krb4 dependency (ticket #419).
Last night, Geoff and I discussed each of the issues and have
settled on the following plan for how we can bring nmh into the
brave new world, dump its source from our tree, and end up without
having to build it at all in the foreseeable future:
1)
Since the Cyrus servers won't be able to speak GSSAPI on the
poNN.mit.edu addresses without breaking that crufty Eudora,
we'll ask Network to have it not exclude the GSSAPI mechanism
on the pop daemon bound to the poNN.mail.mit.edu address just
as was done for IMAP. Cyrus supports POP-over-GSSAPI by default,
so this is simply making the IMAP and POP configs consistent.
When nmh isn't using Hesiod to find the mail server, we'll
need to let it know how to find the right one. We could patch
the code to do this, but that's a bad plan. There's a global
config file we can set the host in, but shell expansion doesn't
happen in it. We can set the MAILHOST environment variable in
everyone's dotfiles, which we believe would be fine. However,
for other reasons (see item 7), we plan to have the
debathena-nmh-config package provide an inc wrapper that passes
it "-host $USER.mail.mit.edu".
2)
The program used to actually send a message is "post" by default.
That command tries to connect to your MTA, which doesn't work so
well if you don't have one installed. The "spost" program can be
used instead and sends the mail through sendmail as if invoked on
the commandline. There doesn't appear to be a global config knob
for this. It's configurable in individual users' .mh_profile by
setting "postproc:" to spost. If that had been in the prototype
user's dotfiles from the outset, this wouldn't be an issue, but
we can't do much about that now. If we edit it in, it may break
backwards compatibility with Athena 9 because the paths to the
programs are different. We plan to have debathena-nmh-config
divert post and make it a symlink to spost.
3)
Years ago, Bob committed a patch to the function that closes
mailbox files (mbx_close()) to make it actually check the return
value instead of assuming that a close always succeeds, and
corresponding checks in the programs that call that function.
Without these checks, in AFS if you ran out of quota, you
could try inc'ing mail, and have nmh happily fetch the mail
from the server, incorrectly believe that it was saving it to
your homedir, and then delete it from the server. We need
this patch, and have to Debathenify nmh to keep it. As we've
worked out alternative solutions to all the other issues, this
is the only reason we're aware of that we would need to build
from source. We plan to Debathenify the package for now to
add this code, and will also attempt to get it committed
upstream and get an SRU, at which point we'll be able to
switch to the upstream package.
4)
The binaries aren't in the typical user's $PATH. They'll land
in /usr/bin/mh. Since we need nmh to be available to current
users of it, and don't really want to cause new people to
unintentionally become users, we plan to add /usr/bin/mh to
people's PATH in the global dotfiles conditionally based on
some test along the lines of
[ -e ~/Mail/context -o -e ~/.config/athena-nmh ]
(testing for ~/.mh_profile isn't sufficient because everyone
has that file, and testing for ~/Mail/context isn't sufficient
because people may have changed their directory from ~/Mail)
If you've never used nmh, it won't be in your path. If you
have used it, it will be in your path. If you intentionally
run our /usr/bin/mh/inc wrapper by its full path, you'll
get a ~/.config/athena-nmh and on future logins, it'll be
in your path.
5)
We change the default 'rmmproc' to 'delete'. Since this is
also changed in the prototype user's .mh_profile, everyone has
that customization and we don't need to do anything to carry
it forward.
6)
On Athena 9, we change the BACKUP_PREFIX from "," to ".#" so
that the AFS expunger will catch and punt those files. We
plan to not concern ourselves with patching to carry this
forward.
7)
'inc' needs to be passed the '-sasl' flag. One way to arrange
that would be to put it in an "inc:" line in ~/.mh_profile,
but again we can't edit the existing ones without breaking
compatibility. Instead, we plan to have debathena-nmh-config
divert inc and provide an inc wrapper that passes "-sasl" and
also "-host $USER.mail.mit.edu" (see item 1).
8)
The mhn.defaults file which controls mappings of mime types to
viewers for them is by default (in the upstream codebase) generated
at compile time based on what's present on the system. Athena 9
has always installed our own static mhn.defaults file instead
to include viewers from infoagents and such. Ubuntu also has
chosen to install a static mhn.defaults file of their own. Since
this ought not to be in the critical path of the problem we're
addressing, we plan to have debathena-nmh-config divert
mhn.defaults and install the same static one Debathena is presently
installing. We can later come back to it and clean up the contents
of that file to use more local apps instead of locker apps, but
that cleanup is orthogonal to getting us cleanly upgraded with
SASL capability and out of the business of building from source.
9)
debathena-emacs-config presently has some configuration that points
at where nmh is installed. This will need to be updated with the
new paths, and we plan to move that configuration into the
debathena-nmh-config package at the same time.
Geoff and I believe that this is a mostly complete, coherent, and
clean plan for nmh, and have our own action items to get it
implemented before next week.
comment:3 Changed 14 years ago by jdreed
- Priority changed from minor to major
To paraphrase Mortal Kombat: "FINISH IT!"
comment:4 Changed 14 years ago by jdreed
- Priority changed from major to critical
We are now officially blocking on this. Changing it to a Recommendation is not the answer. This needs to be finished or punted.
comment:5 Changed 14 years ago by geofft
- Status changed from accepted to development
In r24696, r24697, r24698, r24699, and r24700, I've finished what I believe to be the outstanding work, uploaded these packages to -development, and confirmed that I can send and receive mail on Jaunty via inc/comp and MH-E. More testing, including that it works with people's favorite MH-wrapping utilities, works on and that the mbx_close patch still works, would be appreciated.
See also the discussion on ticket 419.
comment:6 follow-up: ↓ 8 Changed 14 years ago by jdreed
Do we need to add /usr/bin/mh to the default set of PATHs? Because it's not in my PATH when I log in (as an Athena user).
comment:7 Changed 14 years ago by geofft
I'm a little unsure if r24696, i.e., having emacs-config Conflict: debathena-nmh (<= 1.0+athena9.4.34-0debathena4) [the last version of the Athena fork], is the right thing. After some zephyr discussion Evan and I think we want it to instead Break: debathena-nmh (<= 1.0+athena9.4.34-0debathena4). In addition, I think I want debathena-nmh-config to Depend on debathena-nmh (>> 1.0+athena9.4.34-0debathena4) to specify that it's depending on a Debathenified upstream nmh, not the Athena fork.
Since neither of us are totally comfortable with Breaks semantics and the aptitude resolver, this should be tested a bit that it does the right thing on Jaunty, Karmic, and Lucid -workstation and -cluster machines.
comment:8 in reply to: ↑ 6 Changed 14 years ago by geofft
Replying to jdreed:
Do we need to add /usr/bin/mh to the default set of PATHs? Because it's not in my PATH when I log in (as an Athena user).
See point 4 in the transition plan; if you've ever run /usr/bin/mh/inc by hand (which sets a flag in ~/.config), or if you've ever used MH and a ~/Mail/context file has been generated, it's added to your PATH on login.
I'm not terribly opposed to adding it to your path unconditionally, but the reason Debian moved it is that it has lots of names like "scan" and "send" and "show" and "pick" that other programs might want. (See, for instance, r24124, adding a Conflicts from the old package to dvb-apps, which has a /usr/bin/scan.) So I could see it getting in the way of lockers, etc.
comment:9 Changed 14 years ago by broder
- Status changed from development to proposed
I've moved this into proposed after doing some testing on the fixes proposed in comment:7
comment:10 follow-ups: ↓ 11 ↓ 12 Changed 14 years ago by geofft
Do we need to do anything with the install-mh command, like add the same sort of path-modifying wrapper we have around mh, or symlink /etc/nmh/mh.profile to /usr/prototype_user/.mh_profile, or whatever?
Do we want to use install-mh -check instead of the tests we currently have?
I'm guessing no for both ("nobody on Athena uses it" and "meh", respectively), but I figured I'd mention it.
comment:11 in reply to: ↑ 10 Changed 14 years ago by jdreed
Replying to geofft:
Do we need to do anything with the install-mh command, like add the same sort of path-modifying wrapper we have around mh, or symlink /etc/nmh/mh.profile to /usr/prototype_user/.mh_profile, or whatever?
I'm not sure what you're asking here. What would install-mh do differently if we wrapped it?
~/.mh_profile comes from prototype_user. And if it exists, install-mh -auto will fail with "invocation error". So, I'm not convinced install-mh ever got run in the Athena environment, though I could be wrong. (Did ~/.mh_profile actually get copied from the moira server at account creation? I believe it did.)
Among other things, our ~/.mh_profile sets some now-useless mode bits, sets the editor to emacs, and sets the rmmproc to delete(1). So if we haven't already done so (I haven't looked), we should make sure that the new global profile we're shipping sets that if we want to start using it via install-mh -auto
Do we want to use install-mh -check instead of the tests we currently have?
"meh"
comment:12 in reply to: ↑ 10 Changed 14 years ago by jdreed
Replying to geofft:
Do we want to use install-mh -check instead of the tests we currently have?
Actually, I'm going to change my response to an emphatic "no", since we test for ~/Mail/context, which means they're actually _using_ NMH, as compared to have some old mailboxes sitting around that are being read by Pine or Evolution (neither of which touch the context file (I hope?))
jdreed@infinite-loop:~$ [ -e ~/Mail/context ] || ( [ -r ~/.config/debathena/nmh-in-path ] && [ yes = "$(cat ~/.config/debathena/nmh-in-path)" ] ); echo $? 1 jdreed@infinite-loop:~$ /usr/bin/mh/install-mh -check; echo $? 0
comment:13 Changed 14 years ago by jdreed
To clarify, those shell snippets were on an account that had ~/.mh_profile and an empty ~/Mail.
comment:14 Changed 14 years ago by broder
- Status changed from proposed to closed
- Resolution set to fixed
This has been moved to production.