Bug#676424: Bug#454778: Bug#676424: Bug#454778: emacsen-common: load-path order vs debian-run-directories
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 a lot of dangling X.Y directories before that change. Are the X.Y bits all unused by debian add-ons now? Or at least are supposed to be unused. If so then I suppose it wouldn't matter what the X.Y/site-lisp is or is not! :-) -- if that made an empty directory there tempting. I think it's possible that Emacs may have some normal behaviors that cause it to select the X.Y directory for some things -- but regardless, having the symlink means that we don't have to care about what current or future Emacs versions (or packages) do on that front. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676424: Bug#454778: emacsen-common: load-path order vs debian-run-directories
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 by a flavour upgrade and that remove fails for some reason then bits are left behind in what's now an old directory. The symlink was added originally b/c without it, we ended up with a lot of dangling X.Y directories. Are the X.Y bits all unused by debian add-ons now? Or at least are supposed to be unused. If so then I suppose it wouldn't matter what the X.Y/site-lisp is or is not! :-) -- if that made an empty directory there tempting. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676424: Bug#454778: emacsen-common: load-path order vs debian-run-directories
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 close to a release. Ok. If took away the 24.2/site-lisp symlink as thought in the policy then I suppose the load-path would be cleaned up. Or if it was an actual directory instead of a symlink -- if that wasn't yet more confusing. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676424: Bug#454778: emacsen-common: load-path order vs debian-run-directories
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 we should attempt right now, this close to a release. Ok. If took away the 24.2/site-lisp symlink as thought in the policy then I suppose the load-path would be cleaned up. I suspect we need to keep the symlink, unless we want to deal with the possiblity of having to fix a lot of other things (add-ons, etc.). Here's one bit of rationale from emacs/debian/rules: # 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. mv $(pkgdir_common)/usr/share/emacs/$(runtime_ver)/site-lisp \ $(pkgdir_common)/usr/share/$(flavor) dh_link -p$(flavor)-common usr/share/$(flavor)/site-lisp \ usr/share/emacs/$(runtime_ver)/site-lisp The symlink was added originally b/c without it, we ended up with a lot of dangling X.Y directories. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676424: Bug#454778: emacsen-common: load-path order vs debian-run-directories
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 to match the practice :-). If we're only going to have one of them load-path, the flavor directory would be the more stable choice -- right now, though, I can't see how it's being added in the first place. Offhand, I don't see code for that in either emacsen-common or in emacs24, but perhaps I've missed it. Hmm. Does emacs -Q own startup put all subdirs like /usr/share/emacs/24.2/site-lisp/emacs-goodies-el, then debian adds /usr/share/emacs24/site-lisp/emacs-goodies-el/ You'd be tempted to prune out the /24.2/ ones if they're merely symlinks to the debian ones. It looks like all the 24.2 is at the same place in the load-path order. So top-level, I've thought for a while that we probably need to 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 close to a release. For now, I'm inclined to fix the /usr/local issue, and then hope to continue this discussion after the release. Plausible? Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676424: Bug#454778: emacsen-common: load-path order vs debian-run-directories
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 debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676424: Bug#454778: emacsen-common: load-path order vs debian-run-directories
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 certainly welcome, though I *am* almost certainly cleaning up my own mess... -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676424: Bug#454778: emacsen-common: load-path order vs debian-run-directories
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 the string objects -- so that remq will only remove the exact string objects that we add. So if those dirs were already in load-path, they'll stay. That was my intent -- please shout if you think that's either not what it's doing, or not what it should be doing. Incidentally, one thing I never understood was why load-path has entries for both /usr/share/emacs24/site-lisp/emacs-goodies-el and /usr/share/emacs/24.2/site-lisp/emacs-goodies-el I see /usr/share/emacs/24.2/site-lisp is a symlink to /usr/share/emacs24/site-lisp, so I imagine the second doesn't add anything ... if that's true for all flavours etc etc. Hmm. I'll have to investigate -- offhand, I don't see why we need emacs24 in the load-path as long as we have the symlink... 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 the normal site-lisp directory. For example, instead of the emacs23 package having /usr/share/emacs/23.2/site-lisp, it should only have /usr/share/emacs23/site-lisp. This is important because it allows us to avoid having dangling directories for old versions across upgrades. We could have chosen to keep a compatibility symlink, but that seemed likely to mask bugs in the debianized packages. Apparently I either wrote incorrect policy, or I can't actually follow my own policies. Anyone see something I'm overlooking? If not, then perhaps I should remove that symlink in emacs24 (at least), but first I'll see if I can track down why/when it was added, in case there was a good reason. Thanks for the help. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676424: Bug#454778: emacsen-common: load-path order vs debian-run-directories
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 the normal site-lisp directory. For example, instead of the emacs23 package having /usr/share/emacs/23.2/site-lisp, it should only have /usr/share/emacs23/site-lisp. This is important because it allows us to avoid having dangling directories for old versions across upgrades. We could have chosen to keep a compatibility symlink, but that seemed likely to mask bugs in the debianized packages. Apparently I either wrote incorrect policy, or I can't actually follow my own policies. Anyone see something I'm overlooking? 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). If we drop the symlink, then we'd have to figure out if/when that might happen, and fix each occurrence. I suspect just keeping the symlink is easier, but even so, we probably don't need both directories in the load-path. If we're only going to have one of them load-path, the flavor directory would be the more stable choice -- right now, though, I can't see how it's being added in the first place. Offhand, I don't see code for that in either emacsen-common or in emacs24, but perhaps I've missed it. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676424: Bug#454778: emacsen-common: load-path order vs debian-run-directories
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 packages may look for that particular directory by name (which sounds plausible to me). Sounds likely ... change the policy to match the practice :-). If we're only going to have one of them load-path, the flavor directory would be the more stable choice -- right now, though, I can't see how it's being added in the first place. Offhand, I don't see code for that in either emacsen-common or in emacs24, but perhaps I've missed it. Hmm. Does emacs -Q own startup put all subdirs like /usr/share/emacs/24.2/site-lisp/emacs-goodies-el, then debian adds /usr/share/emacs24/site-lisp/emacs-goodies-el/ You'd be tempted to prune out the /24.2/ ones if they're merely symlinks to the debian ones. It looks like all the 24.2 is at the same place in the load-path order. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676424: Bug#454778: emacsen-common: load-path order vs debian-run-directories
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 /usr/share/emacs24/site-lisp/emacs-goodies-el and /usr/share/emacs/24.2/site-lisp/emacs-goodies-el I see /usr/share/emacs/24.2/site-lisp is a symlink to /usr/share/emacs24/site-lisp, so I imagine the second doesn't add anything ... if that's true for all flavours etc etc. -- The sigfile covers series: I drank a slab and the slab won. (to the tune of I Fought the Law) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676424: Bug#454778: emacsen-common: load-path order vs debian-run-directories
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 Kevin's patch and fix the two Cc'd bugs, unless you object or someone explains why this would be a bad idea. Thanks for your work on emacsen-common! Looking in to it now. Feel free to ping me again if you don't hear back in the next week or so. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676424: Bug#454778: emacsen-common: load-path order vs debian-run-directories
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 it doesn't look right. 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 the time, but... I'll try to generate a new release this weekend. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676424: Bug#454778: emacsen-common: load-path order vs debian-run-directories
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 the time, but... I'll try to generate a new release this weekend. Excellent! Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676424: Bug#454778: emacsen-common: load-path order vs debian-run-directories
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, but failed to see it due to editing the regular file (/usr/share/emacs/site-lisp/debian-startup.el) instead of the symlink. Hence, I'm removing the patch tag. Of course, feel free to correct me if I misunderstood the intended effects of the patch. It still works for me and has the desired effect. Confirmed, nice work. Adding the patch tag back. Sorry for the confusion. Rob, how about applying this patch to fix #454778 and #676424? (Please note that the latter is RC for Wheezy, that's why I landed here in the first place.) But packages which mangle load-path themselves are unchanged. If they put themselves at the front of the load-path they that's where they stay. (A deliberate decision so as not to upset anything which has to or had to force an order ...) Yes. This will be for other bug reports, I guess. Let's fix that one first. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
