Your message dated Fri, 11 Aug 2017 18:38:25 +0000
with message-id <e1dgepf-0007hj...@fasolo.debian.org>
and subject line Bug#871627: Removed package(s) from unstable
has caused the Debian Bug report #167805,
regarding emacs21-el: separate .el from .elc files to make debugging more
convenient
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
167805: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=167805
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: emacs21-el
Version: 21.2-1
Severity: wishlist
If .el files were never in the same directory as the corresponding .elc file,
controlling whether the .el or .elc file is loaded would become much easier. I
have used the trick of excluding directories containing the .elc files from
`load-path' at startup to get an Emacs process that is running only source
code. This can make debugging a problem more efficient, especially in the
early stage before you've located the problematic library.
The convention (policy?) for Debian add-on packages is to separate the .el from
..elc files, and this is nice: in my site-start.el, for example, I can take a
cue from an envariable to remove all paths beginning with
/usr/share/emacs21/site-lisp/ from `load-path', and all (or most...) add-on
packages will now load from source instead of byte-compiled files.
It would be also nice if the sources for the base libraries were likewise
separated. If one did this, the .elc directories would need to precede the .el
directories in `load-path', or else the .el files would always be loaded.
When the .elc and .el files are in different directories, you lose the check
(and possible warning), when loading an .elc file, that the .el file is newer
than the .elc file. (The code that checks looks only in the current directory
for an .el file -- this is all in lread.c.) I don't see this as a loss when we
are dealing with .deb packages; when doing one's own coding, one keeps the .el
and .elc files in the same directory, but I think that when using official
..debs, we can trust that the .elc will not be out of date wrt the .el.
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux beth 2.4.19 #1 Mon Aug 26 00:56:45 EDT 2002 i686
Locale: LANG=en_US, LC_CTYPE=en_US
Versions of packages emacs21-el depends on:
ii emacs21 21.2-1 The GNU Emacs editor.
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 24.5+1-11+rm
Dear submitter,
as the package emacs24 has just been removed from the Debian archive
unstable we hereby close the associated bug reports. We are sorry
that we couldn't deal with your issue properly.
For details on the removal, please see https://bugs.debian.org/871627
The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.
This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmas...@ftp-master.debian.org.
Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)
--- End Message ---
