Subject: Re: updating emacs Q
To: None <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 12/21/2001 16:13:08
[ On Saturday, December 22, 2001 at 01:34:57 (+0900), Masao Uebayashi wrote: ]
> Subject: Re: updating emacs Q
> I thought Pkgsrc is to be as simple as possible, keep one package
> source (editors/emacs) par package (Emacs-*), to make package source
> maintainance easier. But I'm moving to think that overwriting (very)
> differenct version of package source may make maintainance harder in
> terms of CVS.
Forget the CVS issues -- it's only barely useful for anything medium or
long term in pkgsrc anyway..... (especially for patches, at least while
they're kept in separate files the way they are now)
CVS isn't there to make pkgsrc module maintenance easier in the sense I
think you're refering to, it's really there only to mediate between
multiple, remote, developers. The only history that's really of any
major use is the most recent delta.
> Emacs 21 has been _not_ released very long term. It seems okay now
> that we have only 21 just after 21 released, but what if 22 will be
emacs-22.x won't likely be released for a very long time yet, though
21.2 will hopefully be released in the near future. I've not yet heard
of any pretests for it, but I expect them to be available to pretesters
early in the next year, and hopefully 21.2 would be available in the
spring sometime. There were some rumblings about making the CVS tree
publicly accessible, but I've not heard anything definite yet.
> The point is that Emacs package and packages depending on it
> have to be all version-aware and be easy to be corrected to work with
> the new version if released.
Very few packages should depend on the specific version of emacs that's
installed (though some must unfortunately differentiate between GNU
Emacs and Xemacs). The only trick is that for ideal binary
compatability it's important any .elc files in binary packages be
compiled with the oldest supported version (or that they be compiled at
install time, not at build time).
> I also think multiple version packages whose compatibility are
> critical to users should be maintained in the Pkgsrc tree. These hit
> Emacs, gtk, Perl, Python, libpng, ...
I do tend to agree, and ideally it should be possible to install
multiple versions simultaneously too, especially with packages like
Emacs where support for this ability is inherent in the native package.
> It's better for us to keep in mind that NetBSD is often used on small
> / old machines. Better to be able to satisfy minimalists' demand, for
> example, by spliting a package into binary and document and make them
That's where editors/jove shines. If you're a minimalist emacs fan then
jove is the ideal compromise:
text data bss dec hex filename
952509 2143768 0 3096277 2f3ed5 /usr/pkg/bin/emacs-20.7
1226854 3290724 0 4517578 44eeca /usr/local/bin/emacs-21.1
127135 7972 80364 215471 349af /usr/pkg/bin/jove
> Is this really small difference!?
I'd say an order of magnitude would be a "large" difference.... :-)
> (BTW, 21.1 is incredibly unstable on my box. :-|)
That is not good to hear. What processor architecture do you have?
Have you been able to report any core backtraces to bug-emacs?
(I have occasional loops where keyboard interrrupt (C-g) doesn't get
sent to the X11 client, but 'kill -2' instantly kills the process, and
I've had one core dump that according to RMS seems to be in the garbage
collector where he says it's very hard to debug.... RMS suggests using
SIGSTOP and then following the instructions in etc/DEBUG to see where
Emacs is looping.)
Greg A. Woods
+1 416 218-0098; <email@example.com>; <firstname.lastname@example.org>; <email@example.com>
Planix, Inc. <firstname.lastname@example.org>; VE3TCP; Secrets of the Weird <email@example.com>