Numbering changes for emacs in pkgsrc

Emacs in pkgsrc is going to be all numbered versions, as in emacs24 and emacs25, etc.  Installing just ’emacs’ will get the current default version, which is emacs 2.4 24.1 right now and I think will be emacs 2.5.  All this will come after the pkgsrc freeze for 2012Q2 is over, which means it will be next month.  Follow the thread on tech-pkg@netbsd.org for details, or to figure out what I said wrong in my summary.

I always talk about vi and vi-like items here, so here’s my ‘equal time’ post.  

Update: as several people pointed out, I had version numbers wrong.  The story is corrected to make it slightly less wrong.

2 Replies to “Numbering changes for emacs in pkgsrc”

  1. Um, it’s Emacs 24, not 2.4. It outnumbered Chrome even before it was released. :-)

    Speaking of vi-like, I’m going to update our editors/vim to vim7.3 after freeze. :-) I’m running it currently on my laptop without problem.

  2. With regards to emacs 25, the way I’m reading this is as follows:

    * they had an unversioned emacs package that would install a version of emacs 23. They also had an emacs-snapshot that would install a pre-release version of the emacs 24 line, whose release has been anticapated for some time and was relatively stable for the last few months as it neared release.

    * now that emacs 24.1 is out, Dave Holland suggests they change that scheme. Rather than have the plain emacs package be emacs24, he wants to do away with an emacs package entirely, at least as a normal package (he’s got an alternative scheme using emacs as a meta-package (whatever that is) and variables (make variables I assume) but I don’t really know pkgsrc so I don’t know what he’s talking about).

    * but getting back to emacs25, it will be packaged as emacs-snapshot at some point, not as emacs, but not right away. Right now it wouldn’t make any sense since to do a snapshot package since the GNU folks have only just cut the 24.1 release and the next major is only a wispy bit of vapour in their minds. So in the mean time, he’s suggesting to mark emacs-snapshot as broken and obsolete. When upstream bzr has something people other than emacs developers want to run, they can update the emacs-snapshot package and mark it unbroken.

    Does that sound right?

Comments are closed.