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
