(See below for why this message is cross-posted to several bugs.) Agustin Martin <[EMAIL PROTECTED]> writes:
> On Mon, May 09, 2005 at 10:01:05PM +0200, Daniel Brockman wrote: >> Package: dictionaries-common >> Version: 0.25.9 >> Severity: normal >> >> Steps to reproduce: >> >> apt-get install dictionaries-common aspell-sv (or some other) >> apt-get install --reinstall emacs21 > > If I am not wrong, that should also be reproduced by a plain > > # dpkg-reconfigure emacs21 Yes, you are right. > I can only check that now in a woody+dict-common system, and I > cannot reproduce that problem. I am not in dial up and cannot try a > real reinstall. Please check if 'dpkg-reconfigure emacs21' also > gives that problem in your system. Please also provide info about > the emacs version you are trying. It does. I'm using emacs21-21.4a-1 (and CVS Emacs from last night, packaged with Jerome Marant's emacs-snapshot). > After your description, every upgrade should trigger that problem Yes, I believe it does, but I have not been able to confirm this. > (As a matter of fact a harmless error message is sometimes shown for > xemacs probably due to that problem), but I could never see it for > FSF emacs, and I have gone through a number of > install/upgrade/reinstall runs (I am not sure about reinstalls, but > should be similar). > > I cannot be sure that something in the emacs error handling is not > changed in sid, but I am surprised that I never found that problem > for FSF emacs. I tried to downgrade to Woody's Emacs, but failed (and I don't have time to try harder right now). > I am also surprised that this bug, considering what causes it, has > never been reported. Indeed, me too. > Read below for a possible reason. >> This likely results in dpkg failing noisily upon running the >> emacs-install script for some completely unrelated Emacs package. >> You won't be able to get your Emacs back unless you first remove >> dictionaries-common. Then you can install Emacs, and finally put >> back dictionaries-common if you like. >> >> This becomes a real problem when you want to install a new Emacs >> flavor (something which also provokes this bug). The worst part >> may be that the error messages give no hint about what is really >> causing the problem. >> >> The problem is that /etc/emacs/site-start.d/50dictionaries-common.el calls >> >> (load "/var/cache/dictionaries-common/emacsen-ispell-dicts.el" t) >> >> and /var/cache/dictionaries-common/emacsen-ispell-dicts.el calls >> >> (debian-ispell-add-dictionary-entry ...) >> >> which causes the autoload for `debian-ispell-add-dictionary-entry' >> to attempt to load the library "debian-ispell". Here's where >> things break down. > > dictionaries-common emacsen-install is called with --no-site-file > for emacs21* and with -no-site-file for xemacs21*, so that > configuration files (etc/etc/emacs/site-start.d/* stuff) should not > be loaded, look at the *real* dictionaries-common section > > install/dictionaries-common: Byte-compiling for emacsen flavour emacs21 > Wrote /usr/share/emacs21/site-lisp/dictionaries-common/debian-ispell.elc > Wrote /usr/share/emacs21/site-lisp/dictionaries-common/ispell.elc > Done > > (No loads from /etc at all) > > But other packages might have missed this, and they are blindly > loading everything under /etc/emacs/site-start.d when > byte-compiling. Can you please submit the full byte-compile log?, so > we can better locate the problem. Yes, you are quite right. I can't believe I missed this. The error does not occur unless I also have auctex installed (some other package that I do not have installed and whose first letter is a, b, c, or d might also provoke it). There are quite a few packages that cause everything in /etc/emacs/site-start.d to be loaded when they are byte-compiled; fortunately, their install/$package scripts all run *after* dictionaries-common's. These packages should probably be fixed, since their correct functioning depends on essentially arbitrary conditions: Let Q be a package such that Q's /etc/emacs/site-start.d script prevents Emacs from starting without --no-site-file until Q's files have been byte-compiled (examples of such packages currently include dictionaries-common, bbdb and dictionary-el). Then a package P whose install/$package script invokes emacs without --no-site-file (there appears to be quite a few of these) cannot be installed at the same time as Q, unless P's name sorts lexicogragraphically *after* Q's. >> I don't know what would be a good solution in this case, but you >> may find it helpful to know that I've filed a similar couple of >> bugs on the dictionary-el and BBDB packages (Bug#308335 and >> Bug#308336, respectively) --- which also cause this same problem. > > The trivial fix is to surround the code by a condition-case, so we > work around other packages bugs. I do not think that is desirable, > so I wait for your log. I agree. Sorry, I do not have time to investigate further and/or create a log right now, but I will follow up on this tonight. > Note that those other packages might also not be guilty for > this problem. Yes. I'm CCing the other bugs so that the maintainers of those packages (bbdb and dictionary-el) do not have to worry so much about this. (Sorry guys!) Maybe these bugs can even be closed. (Assuming that it actually is considered OK for a package to require byte-compiled files in their /etc/emacs/site-start.d scripts.) > Thanks for your report, ... and waiting for your feedback, Thanks for the insightful and quick reply. -- Daniel Brockman <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
