[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XEmacs package code
From: |
Michael Sperber [Mr. Preprocessor] |
Subject: |
Re: XEmacs package code |
Date: |
Thu, 23 May 2002 11:59:58 +0200 |
User-agent: |
Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.5 (bok choi, i386-unknown-freebsd4.5) |
>>>>> "Stefan" == Stefan Monnier <monnier+gnu/address@hidden> writes:
Stefan> You obviously have a lot of experience with such a package system, so
Stefan> I'd love to know more about the details and the reasons for those
details.
Stefan> I was imagining a system as follows:
Stefan> Packages distributed as a directory (like url, w3, gnus, x-symbol, ...)
Stefan> get installed into <prefix>/w3-3.0.45. Packages distributed as a single
Stefan> file get installed into <prefix>/<subdir>/<filename>.el(c)
Stefan> The user then puts in his .emacs (and/or site-lisp/site-start.el) a set
Stefan> of versioning options:
Stefan> (load "<prefix>/w3-3.0.44/autoloads")
Stefan> (load "<prefix>/subdir-beta/autoloads")
Stefan> These "autoloads" file add their directory to the load-path and
Stefan> setup the usual autoloads and auto-mode-alist kind of things.
Stefan> So you can install several versions of packages and the user chooses
Stefan> which one she wants. For single-file-packages, she can only choose
Stefan> on a group-of-packages basis, where the grouping is up to the installer.
Stefan> Now this does not automatically handle the issue of "package X wants
Stefan> version Y of package Z", but it lets the user take care of it.
Stefan> And of course, if we assume that the (load "foobar/autoloads") commands
Stefan> are added by the package-manager, the dependencies could still be
Stefan> obeyed without the user having to do anything, as long as some kind
Stefan> of dependency-description language like the one you propose is available
Stefan> (but that would be a separate layer).
Stefan> Alright, I haven't really asked too many questions, have I ?
Stefan> I'm not sure what question I want to ask apart from
Stefan> - is the above hopelessly flawed ?
Stefan> - if not, does it look anything like what you have in mind ?
It looks almost exactly like what I have in mind, except my has
provisions for doing automatically what you have the user "take care"
of. I do think, however, that the latter is crucial. In cases where
this becomes relevant, the symptoms of bad package interaction are way
too bad for the user to figure out.
Stefan> - what are the layer/decomposition you're considering ?
Stefan> there are obviously several issues:
Stefan> - package format when installing.
I'm all for .tar.gz.
Stefan> - package format once installed.
I intend to keep the specification of that as loose as possible.
Stefan> - representation of dependency.
Stefan> - who/when do we use the dependency info.
Stefan> - ...
That stuff is in the draft, I believe. It's the most elaborately
formulated part of all that's there.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla