>>>> "Martin" == Martin Buchholz
<martin(a)xemacs.org> writes:
Martin> it. (Dear readers: sorry, but the fact that you're
Martin> reading this puts you into the lunatic fringe)
I skipped that part ;->
Martin> It might make sense to have supported and unsupported
Martin> packages, (and the supported ones are seamfully bundled
Martin> with XEmacs), but we're not currently doing this either.
Who is the designer of the plist fields in the `package-get-base'
alist?
I assume it's Steve L. Baur, whose disappearance from
xemacs-.*(a)xemacs.org is still a mystery to me.
One field is called `standards-version'. Currently all packages in
/anonymous@ftp.xemacs.org:/pub/xemacs/packages/package-index.LATEST.pgp
have a 1.1 standards-version.
How about bumping this standards-version to 21.2 for all packages
known[1] to only work with (emacs-version>= 21 1)?
All "stable" packages could be bumped to standards-version to 21.1.
Then it should be fairly easy to change to PUI UI to offer the users
to upgrade to the latest package of a certain standards-version. The
default could be a standards-version of
(string-to-number
(format "%d.%d" emacs-major-version emacs-minor-version))
to make things easy for the novice user.
KJ> the packages they need to get work done. So I think providing
KJ> a fancy interface over the package system is largely a waste
KJ> of time. We need a way to keep unstable packages from the
Not if you're concerned about "market share", I think.
KJ> stable ones, so the user gets a choice. We need a way for the
KJ> user to easily see what they need to install to get a certain
KJ> feature.
Martin> Again, the user should be able to get an excellent editor
Martin> by following these simple and obvious steps:
Martin> tar xf
Martin> configure
Martin> make
Martin> make install
Martin> After that, the user should be able to customize to his
Martin> heart's content, including removing and adding new pieces
Martin> of functionality.
Martin> How the content of that user tarball is subdivided into
Martin> development projects is up to us.
Having standards-version should also make the package maintainer's and
sumo package wrestler's life easier.
Martin> Martin
Best regards,
Adrian
Footnotes:
[1] or assumed, for a start