When installing the dev-util/subversion package, Portage generates an auto-load lisp file under /usr/share/emacs/site-lisp/ . On my machine, the file is: /usr/share/emacs/site-lisp/70svn-gentoo.el Two libraries are prepended to the *front* of the site-wide emacs library path. This means that the emacs libraries in the subversion ebuild is load instead of those included in the emacs installation. This behavior is wrong. The two libraries are: vc-svn psvn The library psvn is not included with Emacs, and so the library path order is irrelevant. No other ebuild contains it (to my knowledge). However, the library vc-svn included with subversion is a deprecated library. In the comments of the library file, it says that it should not be loaded if your Emacs comes with vc-svn as it is old and obsolete. Currently the following conflict exists between app-editors/emacs (or -cvs) and dev-util/subversion: If the installed Emacs version contains vc-svn, it will be ignored in favor of the old and obsolete library. This causes grief and bugs for the user. The generated autoload could be changed from: (setq load-path (cons "/usr/share/emacs/site-lisp/subversion" load-path)) to: (setq load-path (append load-path '("/usr/share/emacs/site-lisp/subversion"))) But honestly, this will not solve the issue due to Emacs searching its own libraries last. The subversion ebuild should do one of the following: (1) detect whether app-editor/emacs or app-editor/emacs-cvs is the editor installed; if emacs-cvs, do not install vc-svn.el (2) patch the vc-svn.el file to find and load the native vc-svn if it exists (load-file "..."), otherwise continue loading itself. (3) provide a use flag to prevent install of old lisp code, perhaps use 'emacs' and 'emacs22' or 'emacs' and 'emacs-cvs' are relevant. (4) provide the user with a warning message on how to avoid the issue Glad to contribute any ideas/elisp patches.
I'd prefer your second solution. The vc-svn.el script is a file in the tree so any better version would do (as long as it is compatible)
Another possibility would be to install vc-svn.el* in a different directory (say, ${SITELISP}/${PN}/compat). Then the site-init file could add it to the load-path for Emacs versions < 22 only: (add-to-list 'load-path "@SITELISP@") (and (< emacs-major-version 22) (add-to-list 'load-path "@SITELISP@/compat"))
(In reply to comment #2) That would be an excellent solution. One caveat though. Emacs 22 appears to recursively search the site-lisp directory for elisp files; so even if the directory is not explicitly add to `load-path', if it is under a directory in the path, it will still be found by `locate-library'. IMHO, a better solution would be to install `vc-svn.el' at /usr/share/subversion/emacs/ in similar fashion to `clisp' and other portage packages. Then site the load file can conditionally add that directory the `load-path' base on the Emacs major version.
(In reply to comment #3) > One caveat though. Emacs 22 appears to recursively search the site-lisp > directory for elisp files; so even if the directory is not explicitly > add to `load-path', if it is under a directory in the path, it will still > be found by `locate-library'. You are right, load-path is augmented by its subdirs in startup.el (function normal-top-level-add-subdirs-to-load-path). This can be prevented by placing a file ".nosearch" within the subdir. So in addition to my comment #2, the ebuild should also install an empty file ".nosearch" in the "compat" directory.
Created attachment 111101 [details] Proposed new 70svn-gentoo.el
Created attachment 111102 [details, diff] Proposed patch for subversion-1.4.3.ebuild
Created attachment 111111 [details, diff] Proposed patch for subversion-1.4.3.ebuild (take 2)
What is the say of the emacs maintainers on this? It seems to be a sane solution, but I'd like your view on it.
(In reply to comment #8) > What is the say of the emacs maintainers on this? It seems to be a sane > solution, but I'd like your view on it. Ulrich is an Officially Trusted Emacs User(TM). :) But I am ok with it, looks fine. Thanks Ulrich, as always.
While you are at it: Is there a special reason why pkg_postrm() does: has_version virtual/emacs && elisp-site-regen instead of: use emacs && elisp-site-regen which is used in pkg_postinst() (and is the more usual way)?
(In reply to comment #10) > While you are at it: > Is there a special reason why pkg_postrm() does: > has_version virtual/emacs && elisp-site-regen > instead of: > use emacs && elisp-site-regen > which is used in pkg_postinst() (and is the more usual way)? I fixed that, pauldv, I hope you don't mind. The rest has been already handled, so this bug can be closed.
Both problems (comment #7 and comment #10) reappeared in 1.4.4-r2, therefore reopening. Versions 1.4.3 up to 1.4.4-r1 were O.K.
*** Bug 185427 has been marked as a duplicate of this bug. ***
Fixed again in 1.4.4-r3, as discussed with phreak on IRC.
