Sven Joachim <[EMAIL PROTECTED]> writes: > Since you're talking in subjunctive here: are you aware of the > snapshots available from http://emacs.orebokech.com/?
No, I wasn't aware of those. Probably because they are not in sid. :-) >> I see two reasons for calling the packages emacs23-snapshot* as >> opposed to emacs-snapshot: >> >> a) There'd be a sane upgrade path once Emacs 23 is released. > > What upgrade path? Do you suggest that emacs23-snapshot should > provide the emacs23 flavor? Otherwise this does not make sense to > me. So far, I was only thinking along the lines of putting proper Replaces Conflicts fields into the emacs23 package once upstream decides to release 23.1. An `emacs23' flavor has the advantage that maintainers of Elisp packages don't need to adjust their packages once a proper emacs23 package hits the archive. >> b) Elisp packages can specify for which package they should be >> byte-compiled. A package that has worked fine with a pre-Emacs22 >> snapshot package might fail once a post-Emacs22 snapshot package if >> we keep the name `emacs-snapshot'. > > If it fails, the package has to be adjusted anyway, if it is using a > blacklist of flavors. And packages using a whitelist will have to be > updated for every new snapshot (or other flavor). Mhm, how many packages use a flavor whitelist and how many use a blacklist? The sample files from debhelper don't seem to favor one or the other. > Which, given the laziness of many maintainers, sucks very much (just > look at how many packages still depend on emacs21). _That's_ a totally different problem whose symptoms might be improved somewhat by mass-filing bugs against those pacakges -- and NMUing if necessary. :-) Cheers, -Hilko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
