Bugzilla Bug 158891

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 an attachment (id=111101) [edit]
Proposed new 70svn-gentoo.el

Created an attachment (id=111102) [edit]
Proposed patch for subversion-1.4.3.ebuild

Created an attachment (id=111111) [edit]
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.