Re: A flaw in current emacsen package setup?

[Rob Browning <rlb@defaultvalue.org>]

Manoj Srivastava <srivasta@debian.org> writes:

> 	Perhaps add-after-local (or a renamed version of the function)
>  should be provided by default, and policy changed to recommend the
>  use of that function.
>
> 	I am copying this message to all packages currently violating
>  the emacsen policy on load-paths. Please consider this fair warning
>  for serious bugs to be filed when we reach a solution of this issue.

Hmm.  The current implementation of add-after-local looks effective,
but I'm wondering if, since we have sufficient control over what's
going on, we might be able to do something more precise.  I'm not sure
exactly what yet, but we can discuss that.

One thing I'm wondering about is how many packages modify the
load-path internally, rather than just in a small top-level
initialization file.  If there are (m)any, then we may need to do
something sneakier like grabbing the load-path before running all the
site-lisp.d scripts, then comparing the load-path to the saved copy
and then rearranging load-path based on that to put any additions "in
the right place".  Though we might want to do this on a per-script
basis, rather than just once for all of site-start.d to avoid
inter-dependency issues for packages that have local overrides.

Another option would be to have a slightly smarter add-after-local,
perhaps called emacsen-pkg-add-path that would just handle the issue,
using perhaps similar tricks to the above, and then require all the
add-on packages to use that.  The advantage here is that we can easily
change the policy if needed without any of the packages having to
change their code.

Thoughts?

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD