[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: removing old installations
Re: removing old installations
Mon, 27 Jun 2011 11:52:02 -0700
Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux)
On Sun, Jun 26 2011, Peter Dyballa wrote:
> Am 26.06.2011 um 00:57 schrieb Eric Abrahamsen:
>> I'm quite sure I've removed everything emacs-related from
>> One odd thing is, my emacs man file is located at
>> /usr/share/man/man1/emacs.1.gz (symlinked from
>> /etc/alternatives/emacs.1.gz), but within the FILES section of that
>> page, it gives all the emacs-related paths as /usr/local/*. Not sure
>> what that's about.
> I've forgotten these! And there's more than one file:
> -rw-r--r-- 1 root wheel 6367 9. Jun 21:38 man1/emacs.1.gz
> -rw-r--r-- 1 root wheel 1632 9. Jun 21:38 man1/emacsclient.1.gz
> -rw-r--r-- 1 root wheel 4444 9. Jun 21:38 man1/etags.1.gz
> -rw-r--r-- 1 root wheel 993 9. Jun 21:38 man1/grep-changelog.1.gz
> -rw-r--r-- 1 root wheel 1191 9. Jun 21:38 man1/rcs-checkin.1.gz
> -rw-r--r-- 1 root wheel 37 9. Jun 21:38 man1/ctags.1.gz
> -rw-r--r-- 1 root wheel 1128 9. Jun 21:38 man1/ebrowse.1.gz
> Another area with around 90 files is /usr/local/share/info. And
> there's also /usr/local/share/applications/emacs.desktop!
> The sym-links to /etc/alternatives are *not* from your "private"
> installation of GNU Emacs, they're presumably from Debian (package).
> The reason is that you can have more that one packaged GNU Emacs
> version on your PC. Then *some* man page must be present (similarly
> for the INFO files – and this Debian scheme really works quite fine,
> on my Mac).
>> The bug report data shows that emacs was compiled by Debian.
> So you can be sure now that it's not your own "private" Emacs!
>> I note that --enable-locallisppath includes, among many other paths,
>> the two paths
>> that emacs complains about when it's run from the command line.
>> Among the voluminous output of strace is:
>> access("/usr/local/share/emacs/23.2/site-lisp", F_OK) = -1 ENOENT
>> (No such file or directory)
>> write(2, "Warning: Lisp directory `/usr/lo"..., 80) = 80
>> access("/usr/local/share/emacs/site-lisp", F_OK) = -1 ENOENT (No
>> such file or directory)
>> write(2, "Warning: Lisp directory `/usr/lo"..., 75) = 75
> So presumably they're just *warnings*, not /errors/! You've deleted
> these directory branches when you found that they might contain data
> from your "private" installations, but they were created before when
> you installed some GNU Emacs package.
> I'd recommend to check (the dates of) the MAN and INFO files. This
> step could be performed again after this most important step: remove
> all GNU Emacs packages from your PC to clean the situation as far as
> possible. (Then recheck the places I mentioned in my posts.) Finally
> re-install these packages/this package. It will create the paths GNU
> Emacs is complaining about.
Yes, it turned out that all the man files (even those that claimed that
emacs would be installed under /usr/local) were all part of the debian
install, and were in the right places. The two directories it was
complaining about were part of the proper install, and after they were
recreated the warnings stopped. Just goes to show how often the problem
you think you have isn't the one you actually have.
>> Is my only problem that emacs was compiled with some non-existent
>> directories in the lisploadpath?
> No, I presume that you started cleaning after you had installed the
> first GNU Emacs package (and found some interference of the two
> Emacsen). And during this operation you just removed a few bits too
> much. By removing and reinstalling you'll get these bits back. And a
> sane system!
Yup, that was exactly right.