Package: wget-el Version: 0.5.0-5 Severity: grave While creating a workaround for #492602, I noticed that /etc/emacs/site-start.d/50wget-el.el contains the following lines:
,---- | (eval-after-load "w3m" | '(load "w3m-wget")) | (autoload 'w3-wget "w3-wget" "wget interface for Emacs/W3." t) | | (eval-after-load "wget" | '(progn | (setq wget-basic-options (cons "-equiet=off" wget-basic-options)) | (setq wget-basic-options (cons "-P." wget-basic-options)))) `---- Whenever the emacs packages are updated, all .elc files are purged and regenerated using the newly-installed version. During the compilation process, one cannot rely on any feature being installed since the source directories are not part of the load-path. emacsen-install scripts for any package that requires features from another package can add that package's source directory to the load-path for its byte-compilation process. (I have added the w3m-el path for sepia as the workaround for #492602.) But there is no sane way for an emacsen-install script to determine whether a third package has modified any of the required features during system startup. The symptom looks like this: ,---- | # apt-get --reinstall install emacs22-gtk | [...] | Wrote /usr/share/emacs22/site-lisp/sepia/sepia-cpan.elc | Wrote /usr/share/emacs22/site-lisp/sepia/sepia.elc | Wrote /usr/share/emacs22/site-lisp/sepia/sepia-ido.elc | Wrote /usr/share/emacs22/site-lisp/sepia/sepia-snippet.elc | Wrote /usr/share/emacs22/site-lisp/sepia/sepia-tree.elc | | In toplevel form: | sepia-w3m.el:37:13:Error: Cannot open load file: w3m-wget | 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) `---- sepia has no dependencies on wget-el at all. After purging wget-el, sepia was byte-compiled fine when I issued: # dpkg --configure emacs22-gtk You should be able to reproduce this behavior on a system with both sepia 0.97-3 (which I have just uploaded) and wget-el installed. Just do an # apt-get --reinstall install emacs22-gtk (or any other emacs22 build). Cheers, -Hilko -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (x86_64) Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages wget-el depends on: ii emacs22-gtk [emacsen] 22.2+2-3 The GNU Emacs editor (with GTK use ii wget 1.11.4-1 retrieves files from the web Versions of packages wget-el recommends: ii w3m-el-snapshot [w3 1.4.263+0.20080321-1 simple Emacs interface of w3m (dev wget-el suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
