Re: XEmacs package code

[sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])]

>>>>> "Stefan" == Stefan Monnier <monnier+gnu/emacs@RUM.cs.yale.edu> 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