Re: Which package would be suitable for password.el?
Steve Youngs <sryoungs(a)bigpond.net.au> writes:
* Simon Josefsson <jas(a)extundo.com> writes:
> I lean towards putting password.el in ecrypto.
That's where I'd put it. Does the ecrypto maintainer have any
objections?:-)
Yup.:-)
password.el in Gnus says:
(if (featurep 'xemacs)
(require 'run-at-time)
(autoload 'run-at-time "timer"))
Where run-at-time.el is:
;; XEmacs has a buggy version of run-at-time. This file defines a
;; non-buggy version of the same.
So it overrides XEmacs core elisp code, even though the core code is
buggy (see other discussion regarding run-at-time).
Adding run-at-time.el too ecrypto is one option, but I'm not sure
working around core bugs in packages is a good idea for the future.
I don't know when (or even if) the bug in core has been fixed. If it
has been in a released 21.4, I think we should simply say people
should use that, and remove the above statement in password.el. The
error is not fatal; their passwords simply expire too fast.
Another option is to rename the run-at-time hack to
password-run-at-time and move the definition into password.el.