Re: Package system improvements!?
Mats Lidell writes:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org>
writes:
> What we really want to do here is install any packages that come
> with the source code in the right place and go from there.
This assumes the source is newer than the packages. Blindly installing
the bootstrap packages from the source might be a bad idea.
Sure. Nobody said blindly, and if there are already packages
installed, the right place may be "nowhere".
> The complexity is entirely due to the fact that for historical
> reasons packages might be anywhere in the user's system, and that
> XEmacs has changed its default location for package installation,
> but the users are going to expect that previously installed packages
> will be found and used.
Maybe we need to limit the scope of what improvements we are trying to
do? It seems like the general case of working perfect under all
circumstances could be hard to tackle at least now. I can't see
through all the twisty little maze of packages anyway!
You're the one who mentioned "blindly". We either try to figure out
what packages the user has installed, if any, and go from there, or we
don't. The latter at least has the advantage of requiring no changes
to existing code, and putting all responsibility on the user. :-)
My original goal was to make the package system work so that a user
could install the binary, from source or from an installer, and go on
from that using what is built in[1] For mercurial or tar-ball-users it
might be solved with an option to configure or a make target!?
For tarball users, this can be solved simply by adding
PACKAGE_INSTALL_ROOT = ＠PACKAGE_INSTALL_ROOT＠
BOOTSTRAP_PACKAGES = ${srcdir}/etc/bundled-packages/bootstrap-pkg.tar.gz
install-bootstrap-packages:
tar -C $PACKAGE_INSTALL_ROOT xzf ${BOOTSTRAP_PACKAGES}
install:: install-bootstrap-packages
to the top-level Makefile (or something like that), and adding a bit
to configure.ac to configure PACKAGE_INSTALL_ROOT.
This won't work for native Windows users, but that probably doesn't
matter.
It also doesn't help for Mercurial users, because we're not going to
put package tarballs in Mercurial. So Mercurial users would require a
different and possibly quite nasty solution. But that doesn't really
matter, either. Mercurial users will have libcurl or libffi solutions
(or even url.el).
The real issue is screwing up people who have existing package
installations that they want reused either because the bootstrap
packages get installed in a different place and XEmacs finds them but
not the existing installation, or because the bootstrap packages
overwrite the user's installation. I don't really care if it's old --
the next thing the user is going to do is to download most recent
versions anyway. The real problem is what if the user has edited
packages that get overwritten? That would suck massively[TM].
More useful is maybe to address the issue with when a user is on an
existing installed system and wants to update or install new
packages. This ought to be of benefit for many users.
What else do you think I've been talking about?!
[1] I actually assumed there would be no previous packages installed
in this scenario but its usefulness might be to limited!?
Usefulness is somewhat limited but clearly significant. The problem
is that anything based on that assumption has the possibility of
destroying people's existing installations.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta