Hendrik Tews <hend...@askra.de> writes:
>
> (setq load-path (append add-on-package-paths old-load-path))))))
This was recently (recently!) noted in bug 117564. I made a report
a time after too, missing the earlier one, as bug 454778.
> This makes the requirement in the Debian Emacs policy
> an absurdity.
Yes as it stands but a bug of the implementation. I think the concept
of keeping the /usr/local sysadmin's things ahead of packages is sound.
> Kevin, you filed quite a lot reports about
> debian-pkg-add-load-path-item. Would you add a note to all of
> them, telling the maintainers that their package may break when
> they switch to debian-pkg-add-load-path-item?
I expect the problem is what you note having two coq.el. Emacs behaves
very badly when there's two .el of the same name. Code expecting one
bombs on the other or vice versa.
M-x list-load-path-shadows can help find names which overlap.
Occasionally a package intentionally supplies a newer version of
something which comes with emacs itself. Otherwise name clashes might
be unnoticed until something breaks, probably breaks badly :-(.
As an idea for lisp sub-parts you might have seen cedet and semantic do
things like
(require 'semantic/foo)
to get at a component file in a subdir, instead of extending the load
path. I don't know how well it works in practice. Plain style
semantic-foo.el would no doubt be more traditional. I have an idea
update-file-autoloads is wrong from such sub-parts, but apart from that
it presumably goes well enough to have been used in cedet.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
