Bug#329114: Please don't shadow emacs-snapshot packages
Rob Browning [EMAIL PROTECTED] wrote: Peter S Galbraith [EMAIL PROTECTED] writes: How likely it is that we can get emacsen-common fixed? That package has seen a single upload since `oldstable' (woody?) Hmm, though there was a long period with no uploads, 1.4.16 was uploaded in January and should be in testing and sarge. That's the single upload I was talking about. :-) Rob, that's great if you can make more uploads. Perhaps then we won't have to worry so much about breaking things if we know stuff can be quickly fixed. I don't recall why the current adding to load-path scheme had to be worked out, but it certainly seems imperfect to me. We must have the ability to add stuff that we either choose to override Emacs' libraries, or not override them if they exist. That's currently not easy to do. Thanks, Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329114: Please don't shadow emacs-snapshot packages
reassign 329114 emacs-goodies-el 24.15-1 retitle 329114 copy .el files next to .elc files for find-function thanks The bug is really fixed now, with last night's upload of 24.15-1. But something should be done to re-allow the inclusion of non-shadowing .el files that the fix broke. Either emacsen-common gets fixed, or I might follow the suggestion of Kevin Ryde to copy the .el file to specific directories like /usr/share/emacs21/site-lisp/emacs-goodies-el/. Could be done via symlinks as well as suggested at the tail end of bug #157123 3 years ago. Yuck, but it would work. I'll keep this bug open for now. Romain Francoise [EMAIL PROTECTED] wrote: reopen 329114 reassign 329114 gnus-bonus-el 24.14-1 severity 329114 normal kthxbye The nnnil and spam-stat packages (mentioned in my initial report) are still shadowed in gnus-bonus-el version 24.14-1. Please fix this as well. Thanks! -- ,''`. : :' :Romain Francoise [EMAIL PROTECTED] `. `' http://people.debian.org/~rfrancoise/ `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329114: Please don't shadow emacs-snapshot packages
Rob Browning [EMAIL PROTECTED] wrote: I'd like to figure out what needs fixing and fix it, but I want to be careful because some of the emacsen-common stuff is trickier than I often think at first glance. I wouldn't have a problem with that, it's your choice. Perhaps there is an alternate solution that we haven't thought of yet... Let me read this thread more carefully and try to understand the issue clearly, and I'll see if I have any suggestions. I've decided to populate the Emacs-flavour specific directiories with symlinks to the real .el files: apt-sources.el - /usr/share/emacs/site-lisp/debian-el/apt-sources.el apt-sources.elc apt-utils.el - /usr/share/emacs/site-lisp/debian-el/apt-utils.el apt-utils.elc deb-view.el - /usr/share/emacs/site-lisp/debian-el/deb-view.el deb-view.elc debian-bug.el - /usr/share/emacs/site-lisp/debian-el/debian-bug.el debian-bug.elc debian-el-loaddefs.el - /usr/share/emacs/site-lisp/debian-el/debian-el-loaddefs.el debian-el-loaddefs.elc debian-el.el - /usr/share/emacs/site-lisp/debian-el/debian-el.el debian-el.elc When you think about it, it's the best way to be sure a file you don't want loaded never get loaded. I presume this should be in Emacs policy? Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329114: Please don't shadow emacs-snapshot packages
reopen 329114 reassign 329114 gnus-bonus-el 24.14-1 severity 329114 normal kthxbye The nnnil and spam-stat packages (mentioned in my initial report) are still shadowed in gnus-bonus-el version 24.14-1. Please fix this as well. Thanks! -- ,''`. : :' :Romain Francoise [EMAIL PROTECTED] `. `' http://people.debian.org/~rfrancoise/ `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329114: Please don't shadow emacs-snapshot packages
Romain Francoise [EMAIL PROTECTED] writes: I don't know, Rob appears to be active but the package has certainly seen less attention than it deserves. It should be about to see substantially more. I'd like to figure out what needs fixing and fix it, but I want to be careful because some of the emacsen-common stuff is trickier than I often think at first glance. I wouldn't have a problem with that, it's your choice. Perhaps there is an alternate solution that we haven't thought of yet... Let me read this thread more carefully and try to understand the issue clearly, and I'll see if I have any suggestions. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329114: Please don't shadow emacs-snapshot packages
Peter S Galbraith [EMAIL PROTECTED] writes: How likely it is that we can get emacsen-common fixed? That package has seen a single upload since `oldstable' (woody?) Hmm, though there was a long period with no uploads, 1.4.16 was uploaded in January and should be in testing and sarge. -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329114: Please don't shadow emacs-snapshot packages
Peter S Galbraith [EMAIL PROTECTED] writes: Anyone have any bright ideas? Create /usr/share/emacs/site-lisp/emacs-goodies-el/flavor/ directories, populate them with symlinks to only the files we want for each flavor, and add that to the load-path instead. It isn't pretty, but it should work... -- ,''`. : :' :Romain Francoise [EMAIL PROTECTED] `. `' http://people.debian.org/~rfrancoise/ `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329114: Please don't shadow emacs-snapshot packages
Peter Galbraith [EMAIL PROTECTED] writes: 1- Perhaps if I don't explicitely add /usr/share/emacs/site-lisp/emacs-goodies-el/ to the load-path, it will get added automatically at the tail end, because it is a subdirectory of /usr/share/emacs/site-lisp ? Nope, it won't be added automatically. 2- Perhaps emacs-snapshot can be modified to have it's generic load-path all done by the time the /etc/emacs startup files are run. That way. add entries at the tail end of the load-path would indeed yield the expected result. For everybody. Not just me. Its load-path is already 'all done' by the time the Debian startup scripts run, or things would break in horrible ways. Your problem is that this code from debian-startup.el (in the `debian-run-directories' function) stores the original load-path before running the scripts and then explicitly overwrites load-path, adding any items added by the Debian startup scripts at the head of the original load-path: , | ;; restore the old load-path -- including any new paths added by | ;; files loaded in directory traversal. | (let ((add-on-package-paths |(delq nil (mapcar | (lambda (item) | (if (not (member item new-path)) | item | nil)) | load-path | (setq load-path (append add-on-package-paths old-load-path)) ` This is why your site-lisp directory added at the end of the load-path in emacs-goodies-el's startup script ends up being moved before the system load path items after `debian-startup' returns. So, we could try to fix emacsen-common by changing this code, or we could try my (admittedly cumbersome) symlink solution... Cheers, -- ,''`. : :' :Romain Francoise [EMAIL PROTECTED] `. `' http://people.debian.org/~rfrancoise/ `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329114: Please don't shadow emacs-snapshot packages
Romain Francoise [EMAIL PROTECTED] wrote: Peter Galbraith [EMAIL PROTECTED] writes: 1- Perhaps if I don't explicitely add /usr/share/emacs/site-lisp/emacs-goodies-el/ to the load-path, it will get added automatically at the tail end, because it is a subdirectory of /usr/share/emacs/site-lisp ? Nope, it won't be added automatically. Okay, thanks. 2- Perhaps emacs-snapshot can be modified to have it's generic load-path all done by the time the /etc/emacs startup files are run. That way. add entries at the tail end of the load-path would indeed yield the expected result. For everybody. Not just me. Its load-path is already 'all done' by the time the Debian startup scripts run, or things would break in horrible ways. Your problem is that this code from debian-startup.el (in the `debian-run-directories' function) stores the original load-path before running the scripts and then explicitly overwrites load-path, adding any items added by the Debian startup scripts at the head of the original load-path: , | ;; restore the old load-path -- including any new paths added by | ;; files loaded in directory traversal. | (let ((add-on-package-paths |(delq nil (mapcar | (lambda (item) | (if (not (member item new-path)) | item | nil)) | load-path | (setq load-path (append add-on-package-paths old-load-path)) ` Well, I'm sure that was done for a valid reason. But isn't it horribly broken? It means we can't do what's best for the load-path. This is why your site-lisp directory added at the end of the load-path in emacs-goodies-el's startup script ends up being moved before the system load path items after `debian-startup' returns. So, we could try to fix emacsen-common by changing this code, or we could try my (admittedly cumbersome) symlink solution... If I have to resort to the symlink solution, everybody who gets this problem will have to do the same thing. If emacsen-common gets fixed, it's fixed for everybody! How likely it is that we can get emacsen-common fixed? That package has seen a single upload since `oldstable' (woody?) I'd rather REMOVE /usr/share/emacs/site-lisp/emacs-goodies-el from the load-path altogether, except that breaks the ability to jump to the code when viewing variables and functions via `C-h v' and `C-h f'. Much easier and cleaner than maintaining a collection of symlinks... Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329114: Please don't shadow emacs-snapshot packages
Peter S Galbraith [EMAIL PROTECTED] writes: Well, I'm sure that was done for a valid reason. Yep, but it's hard to tell which... If I have to resort to the symlink solution, everybody who gets this problem will have to do the same thing. If emacsen-common gets fixed, it's fixed for everybody! How likely it is that we can get emacsen-common fixed? That package has seen a single upload since `oldstable' (woody?) I don't know, Rob appears to be active but the package has certainly seen less attention than it deserves. Perhaps Rob would be willing to hand off maintenance of this package to a team of Emacs people in Debian if we ask. I'd rather REMOVE /usr/share/emacs/site-lisp/emacs-goodies-el from the load-path altogether, except that breaks the ability to jump to the code when viewing variables and functions via `C-h v' and `C-h f'. Much easier and cleaner than maintaining a collection of symlinks... I wouldn't have a problem with that, it's your choice. Perhaps there is an alternate solution that we haven't thought of yet... -- ,''`. : :' :Romain Francoise [EMAIL PROTECTED] `. `' http://people.debian.org/~rfrancoise/ `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329114: Please don't shadow emacs-snapshot packages
Package: emacs-goodies-el Version: 24.12-1 Severity: important The emacs-goodies-el and gnus-bonus-el packages shadow a number of packages included in emacs-snapshot. This is problematic because some of these packages are maintained in Emacs CVS and are newer in emacs-snapshot than in emacs-goodies-el, or may contain changes that are needed for Emacs 22. This is particularly aggravating for ibuffer since the version in emacs-goodies-el is almost *three years* older than the version in Emacs. Affected packages: * emacs-goodies-el: - wdired.el - ibuffer.el - table.el - newsticker.el * gnus-bonus-el: - nnnil.el - spam-stat.el I'd also appreciate if you could make emacs-goodies-el.el stay off emacs-snapshot entirely for these packages, i.e. don't bind keys, don't autoload, etc. This kind of thing in particular isn't needed: | (if (and (= emacs-major-version 22) ; Change these two lines if XEmacs |(not (featurep 'xemacs))) ; contains the wdired package | '(lambda () |(define-key dired-mode-map r 'wdired-change-to-wdired-mode)) The key is not bound in Emacs, I don't see why emacs-goodies-el should bind it on its own... Thanks, -- ,''`. : :' :Romain Francoise [EMAIL PROTECTED] `. `' http://people.debian.org/~rfrancoise/ `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329114: Please don't shadow emacs-snapshot packages
Romain Francoise [EMAIL PROTECTED] wrote: Package: emacs-goodies-el Version: 24.12-1 Severity: important important a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. Hmmm... The emacs-goodies-el and gnus-bonus-el packages shadow a number of packages included in emacs-snapshot. This is problematic because some of these packages are maintained in Emacs CVS and are newer in emacs-snapshot than in emacs-goodies-el, or may contain changes that are needed for Emacs 22. This is particularly aggravating for ibuffer since the version in emacs-goodies-el is almost *three years* older than the version in Emacs. Affected packages: * emacs-goodies-el: - wdired.el - ibuffer.el - table.el - newsticker.el * gnus-bonus-el: - nnnil.el - spam-stat.el I'll add them to the byte-compilation exclusion. I assume it declares a flavor of emacs-snapshot? Or is it emacs22? I'd also appreciate if you could make emacs-goodies-el.el stay off emacs-snapshot entirely for these packages, i.e. don't bind keys, don't autoload, etc. This kind of thing in particular isn't needed: | (if (and (= emacs-major-version 22); Change these two lines if XEmacs | (not (featurep 'xemacs))) ; contains the wdired package | '(lambda () |(define-key dired-mode-map r 'wdired-change-to-wdired-mode)) The key is not bound in Emacs, I don't see why emacs-goodies-el should bind it on its own... You're the first to complain. I'll add a defcustom for it then. -- Peter S. Galbraith, Debian Developer [EMAIL PROTECTED] http://people.debian.org/~psg GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329114: Please don't shadow emacs-snapshot packages
Peter S Galbraith [EMAIL PROTECTED] writes: I'll add them to the byte-compilation exclusion. I assume it declares a flavor of emacs-snapshot? Or is it emacs22? It's emacs-snapshot. The emacs22 packages will have the same problem but I guess there's no need to plan ahead... You're the first to complain. I'll add a defcustom for it then. Thanks. -- ,''`. : :' :Romain Francoise [EMAIL PROTECTED] `. `' http://people.debian.org/~rfrancoise/ `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329114: Please don't shadow emacs-snapshot packages
Romain Francoise [EMAIL PROTECTED] wrote: The emacs-goodies-el and gnus-bonus-el packages shadow a number of packages included in emacs-snapshot. This is problematic because some of these packages are maintained in Emacs CVS and are newer in emacs-snapshot than in emacs-goodies-el, or may contain changes that are needed for Emacs 22. This is particularly aggravating for ibuffer since the version in emacs-goodies-el is almost *three years* older than the version in Emacs. Affected packages: * emacs-goodies-el: - wdired.el - ibuffer.el - table.el - newsticker.el * gnus-bonus-el: - nnnil.el - spam-stat.el There's a problem... Even if I skip byte-compilation of these files for emacs-snapshot, I still add the directory /usr/share/emacs/site-lisp/emacs-goodies-el at the end of the load-path. But this is done too soon during startup and this directory ends up shadowing the emacs-snapshot file /usr/share/emacs/22.0.50/lisp/net/newsticker.elc We need to be able to add to the load-path without shadowing files that may or may not be present (i.e. present in emacs-snapshot but not in emacs21). Anyone have any bright ideas? Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]