Kevin Ryde use...@zip.com.au writes:
Hmm. I suppose if an add-on is removed by a flavour upgrade and that
remove fails for some reason then bits are left behind in what's now an
old directory.
I think there were probably all kinds of reasons -- but I'm fairly
certain that we did end up with
Rob Browning r...@defaultvalue.org writes:
# The version-specific site-lisp dir, say emacs/21.1/site-lisp, needs
# to be in share/FLAVOR so that as we upgrade from 21.1 to 21.2,
# etc., add-on package bits don't get left behind.
Hmm. I suppose if an add-on is removed
Rob Browning r...@defaultvalue.org writes:
investigate our load-path handling more carefully, perhaps even more so,
given that Emacs has changed its behavior over the past couple of major
releases -- but I also think that it's probably not something that we
should attempt right now, this
Kevin Ryde use...@zip.com.au writes:
Rob Browning r...@defaultvalue.org writes:
investigate our load-path handling more carefully, perhaps even more so,
given that Emacs has changed its behavior over the past couple of major
releases -- but I also think that it's probably not something that
Kevin Ryde use...@zip.com.au writes:
Rob Browning r...@defaultvalue.org writes:
I suppose one argument for keeping the symlink is the possibility that
Emacs or add-on packages may look for that particular directory by name
(which sounds plausible to me).
Sounds likely ... change the policy
Rob Browning wrote (02 Dec 2012 20:34:59 GMT) :
For now, I'm inclined to fix the /usr/local issue, and then hope to
continue this discussion after the release.
Plausible?
I think this totally makes sense.
Thanks for tackling this RC bug :)
--
To UNSUBSCRIBE, email to
intrigeri intrig...@debian.org writes:
Rob Browning wrote (02 Dec 2012 20:34:59 GMT) :
For now, I'm inclined to fix the /usr/local issue, and then hope to
continue this discussion after the release.
Plausible?
I think this totally makes sense.
Thanks for tackling this RC bug :)
You're
Kevin Ryde use...@zip.com.au writes:
Rob Browning r...@defaultvalue.org writes:
(let* ((paths (mapcar copy-sequence dirs)) ; Ensure we have unique
objects.
In debian-run-directories? I suspect its rest makes dirs a fresh
list anyway.
It's not the list spine I'm trying to copy, but
Rob Browning r...@defaultvalue.org writes:
And stranger still, debian-emacs-policy appears to forbid the symlink:
/usr/share/flavor/site-lisp should be used instead of the normal
site-lisp directory for that flavor of emacs, and the package for a
given flavor of emacs should not have
Rob Browning r...@defaultvalue.org writes:
It's not the list spine I'm trying to copy, but the string objects
Ah, I see. Yes that might be prudent, though the flavor-dir one
coming in is a fresh concat.
I suppose one argument for keeping the symlink is the possibility that
Emacs or add-on
Rob Browning r...@defaultvalue.org writes:
(let* ((paths (mapcar copy-sequence dirs)) ; Ensure we have unique objects.
In debian-run-directories? I suspect its rest makes dirs a fresh
list anyway.
Incidentally, one thing I never understood was why load-path has entries
for both
intrigeri intrig...@boum.org writes:
(Gentle) ping?
I'd rather wait for a solution #677191 to be available, so that both
remaining RC bugs against emacsen-common can be fixed by the same
upload / unblock request, but if this does not happen shortly,
I intend to NMU emacsen-common to apply
Rob Browning r...@defaultvalue.org writes:
Looking in to it now. Feel free to ping me again if you don't hear back
in the next week or so.
OK, so that (original) code's quite old, but from a quick glance, it
doesn't seem to be doing what I thought it was supposed to be doing, and
I agree that
Hi,
Rob Browning wrote (28 Nov 2012 02:03:07 GMT) :
I'm really not sure how it ended up that way, but regardless, I think I
may use Kevin's approach, with perhaps this additional bit:
(let* ((paths (mapcar copy-sequence dirs)) ; Ensure we have unique objects.
Not likely to matter most of
tags 454778 + patch
tags 676424 + patch
thanks
Hi,
Kevin Ryde wrote (04 Nov 2012 00:15:44 GMT) :
If there's a debian-startup.elc it will load instead of the .el
source of course.
You're totally right, I had
/usr/share/emacs24/site-lisp/debian-startup.elc in the directory of
the .el symlink,
15 matches
Mail list logo
