> Judging from the comments, this installer might more or less get along
> at least with some XEmacs packages, as well as some other packages
> with a regular enough structure (AUCTeX has in the mean time gotten a
> new autoconf-based installer very similar to that of preview-latex, so
> the latest versions probably will not work with install.el).

It might still work, depending on how the configuration is done.  I tend to
think that most of the autoconfiguration should be done upon use rather
than during installation, which basically implies "in elisp rather than in
autoconf".

> a) a directory layout.  XEmacs packages have a standard way of placing
> Elisp, info, data and other files in a layout under the top package
> directory.  In addition there are some standard file names for
> initializing of packages and installation.  In short, this part of the
> package system is basically just file layout conventions relative to a
> package-specific top directory.

> We don't have any conventions for packages intended for Emacs as far
> as I can see.  It certainly would not be bad to have something like
> that: if people make code for Emacs, and if we can agree on some
> layout that makes it easier for stuff to work out of the box, it
> certainly might be worthwhile to state some conventions.

Yes, `install' does not impose a particular structure (it just looks
recursively for *.el files).  But it would benefit from some conventions
(so it can safely ignore the contrib/foo.el or compat/bar.el files).
I can't find any documentation about the in-package layout used by XEmacs,
tho.  Anybody knows where it's described?

> b) version management.  Versions must basically be floats, higher
> versions correspond to later versions, are usually based on some CVS
> archive and not at all with actual package versions.  Uh.

Right, it seems to be used only to discover whether a newer version is
available or not.

> c) a package manager that will download and upgrade packages.  It
> might do so in user-specific and system-wide packages.

> d) central download archives that will provide all packages, updated
> by packagers (often different from the actual creators of software) on
> central servers.

> e) it does not offer AFAIR: dependencies and standard tests (for
> executables, directories and other stuff) that autoconf provides.  A
> bit of framework for that might be nice for obliterating some
> necessities for installation.  Even though installing MSYS is not
> particularly hard, it still seems to be a barrier for some people.

`install' doesn't get involved with version management, dependencies, ...
It only tries to make it easier for users to install and setup external
packages.  A package manager to also allow activation/deactivation/deletion
would be a natural addition.

> I am not convinced about the value of the centralized server approach
> to package management from XEmacs: it does not seem to lend itself

Since `install' specifically targets external packages, a centralized server
doesn't make much sense indeed.  For XEmacs, it was probably
a good simplification.

> But I do think that we should try to offer some way of installing
> external Lisp code if one has acquired it as a zip or tar archive in
> some manner already.

Not just tarballs but also single elisp files.  Most elisp packages are
single files.

> And in those respects where the directory structure and layout
> conventions of an XEmacs package would seem reasonable, there seems
> little point in inventing something else.

Agreed.

> Stefan, having met those problems when writing install.el already,
> would probably be a lot more qualified to comment on my impressions
> and on the versatility of the package layout he has been catering for.

The DWIM-aspect of `install' (just look for *.el and *.info files) only
works up to a point.  I've bumped into problems where some *.el files should
be ignored, or other problems where the *.info file doesn't have the `info'
extension, or where the info file simply doesn't exist and it's not clear
how to build it based on a bunch of *.texi files, ...

We could keep adding intelligence and heuristics, but it makes more sense to
devise some conventions.

> All of those certainly sound reasonable.  In particular, I'd second having
> separate commands for installing system-wide and user-local packages.

Agreed, it makes more sense.


        Stefan


PS: I attached my latest version, which is still "work in progress".