[RFC] SXEmacs Packaging -- The next steps
Steve Youngs <steve <at> sxemacs.org>
2016-05-23 05:07:13 GMT
In this message I'm going to be talking about a bunch of different
XEmacs packages but I don't want this to go on forever so I'm only going
to mention them by name and not describe what they do. If I mention a
package that you're not familiar with you can...
M-x package-get-info RET PKGNAME RET description RET
...and that will give you a brief description of the package. For
M-x package-get-info RET gnus RET description RET
=> The Gnus Newsreader and Mailreader.
OK, now that SXEmacs can leach and install packages via HTTP I think we
should begin distributing our own (built with SXEmacs) packages. I
already have a mirror of the XEmacs packages at
http://downloads.sxemacs.org/xemacs-pkgs/packages which is updated daily
via rsync. The source for those packages originates in XEmacs'
mercurial repo and have been built on XEmacs 21.4 by Norbert Koch. My
immediate plan is to turn off the daily rsync at downloads.sxemacs.org.
And then build those exact same packages here with SXEmacs, and then
replace all the packages at downloads.sxemacs.org with SXEmacs built
My first question:
Should we "go it alone" with packages? By that, what I mean is
should we drop the XEmacs package mirrors and only use SXEmacs
package mirrors/sites? I think this is something we should
consider because I want progress happening in "package-land".
Considering that one no longer needs to jump through hoops and fight GCC
builds to get libffi anymore, can we please please please make libffi a
non-optional requirement for building SXEmacs?
Assuming positive responses to those two questions I'd like to propose
the following changes to the list of packages distributed:
These are the packages that I think we should drop from the list right
now. None of these are set in stone so if you have reasons for keeping
any just speak up. I just don't see the point in distributing packages
that nobody is ever going to want or have a need for.
Sun lol, wut?
build ok, this one _is_ set in stone, it's incompatible with SXEmacs.
calc Don't freak out, read further down and all will become clear.
forms even XE says it's obsolete
gnats the rest of the world moved on to things like bugzilla
pgg easypg is a gazillion times better
tm nothing uses this
tooltalk see 'Sun'
vc-cc non-free and there's a 'clearcase' package anyway
xetla nobody, absolutely nobody, uses tla anymore
What others should we get rid of while we're at it?
New SXEmacs Packages
These are some new packages that will only run in SXEmacs
Calc See, I told you not to freak out. This will be Jay's calc that uses
lots of SXEmacs ENT goodness.
EMchat My IM client, well technically just an ICQ client, but still
with hopes and plans of multi-protocol.
howm "Write fragmentarily and read collectively" According to
the website. I use it, I like it, it's cool. It's probably
not really a "SXEmacs-only" package.
What others would you want to add? How about magit? org-mode? If you
get itchy, start scratching.
XEmacs Packages Updates
These are the packages that are in my sights for immediate updates.
easypg update to author's git
gnus update to the last version that had support for XEmacs
riece update to author's git
I haven't yet decided what to do about package source repos, I'll leave
that for another day.
That's where I'm at right now with SXEmacs and packaging. What say you?
 Unless stated otherwise, whenever I mention "packages" I'm talking
about the pre-built "binary" packages that PUI deals with, not source
 Currently a grand total of one site, but I'm optimistic for the
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| SXEmacs - The only _______ you'll ever need. |
| Fill in the blank, yes, it's THAT good! |
|------------------------------------<steve <at> sxemacs.org>---|