[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
update-directory-autoloads and package management systems
From: |
Daniel Novotny |
Subject: |
update-directory-autoloads and package management systems |
Date: |
Mon, 12 Oct 2009 10:33:48 -0400 (EDT) |
hello,
there's a problem with "update-directory-autoloads", which exposes itself, when
you use some package management system, which builds Emacs in some temporary
build root
and then -on user's machine- installs the files to default directories like
/usr/share
to reproduce the problem, add ";;;###autoload" to random defun
in some lisp file in the distribution and then run M-x
update-directory-autoloads
on some system that installed emacs from rpm or deb package:
tested this on Fedora and Debian
the error message is:
autoload-ensure-default-file: Opening output file: no such file or directory,
/builddir/build/BUILD/emacs-22.2/lisp/loaddefs.el
the problem is, that you compile the lisp files
during the package creation, while you are in the temporary
buildroot, so some path, relative to that, is stored inside the .elc
$ grep '/builddir/build/BUILD' /usr/share/emacs/22.3/lisp/*.elc
-> every file matches
and when you install the rpm (or deb) on target system, the path is
no longer there. package management systems which use chroot for compiling
packages (on Arch Linux and Gentoo for example) do not suffer from this
problem,
because the path is the same in build and installation time - but deb and rpm
are
not designed like this :(
is there a way to customize this path? building all the .elc files
anew on the user's machine every update doesn't seem like a good
solution to me...
regards,
Daniel Novotny, Red Hat inc.
references:
https://bugzilla.redhat.com/show_bug.cgi?id=474958
- Red Hat bug report for this
- update-directory-autoloads and package management systems,
Daniel Novotny <=