Sven Joachim <[EMAIL PROTECTED]> writes: > On 2008-07-26 23:00 +0200, Hilko Bengen wrote: >> Source file `/usr/share/emacs22/site-lisp/sepia/snippet.el' newer than >> byte-compiled file > > Not related to your problem, but this looks strange. Why does the > byte-compiled file exist and why is the source newer?
No idea. This hasn't happened since. > Probably emacs-install would need to be changed to take package > dependencies into account, but the emacsen-common package does not > seem to be maintained currently. I'm not sure whether it's such a good idea to add dependency handling to emacs-install. > I think you can work around this by specifying the path to w3m-perldoc > in the require call, like this: > > (eval-when-compile > (require 'w3m-perldoc "w3m/w3m-perldoc")) > > This will load the file from /usr/share/emacs/site-lisp, if no > byte-compiled file from /usr/share/emacs22/site-lisp exists yet. No such luck: [...] In toplevel form: sepia-w3m.el:37:13:Error: Cannot open load file: w3m Wrote /usr/share/emacs22/site-lisp/sepia/snippet.elc emacs-install: /usr/lib/emacsen-common/packages/install/sepia emacs22 failed at /usr/lib/emacsen-common/emacs-install line 28, <TSORT> line 56. dpkg: error processing emacs22-gtk (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: emacs22-gtk E: Sub-process /usr/bin/dpkg returned an error code (1) It turns out that w3m-perldoc requires w3m which isn't really surprising. :-) My workaround consists of adding the source directory for w3m-el to the load-path when sepia is byte-compiled. Cheers, -Hilko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
