Simon Josefsson <jas(a)extundo.com> writes:
> > Building at installation time would be preferred,
>
> Fully agreed.
IMHO it's not that clear. Today, XEmacs =users= are installing
packages. Not the administrator.
Is that your experience? From what I see, the administrators are
usually expected to set up XEmacs, which they do by downloading the
"SUMO" distribution.
The users who care to download individual packages seem to be the
minority of experts. Maybe things will be different in several years,
but that's how I see things "today."
So it can't be assumed that the user would be able to baby-sit
installing a binary.
You have a point. Still, building the binary at install-time sounds
much better than the proposed alternatives.
IMHO using `rpm' or any other well-known packaging tool, that
has
already went through all these problems and solved them, would be
nice.
Far from nice, I'm afraid. Using a generic packaging tool like RPM
wouldn't really solve the problems, it would just move them to a new
level, one I'm not sure we want to handle. Some of the problems I see
are:
* Whichever solution we choose will be unusable by many users. I, for
one, use Debian and don't want XEmacs to spawn `rpm' with its entire
infrastructure.
* Does RPM even run on Windows?
* Managers like RPM and dpkg are way too complex for what we need, and
yet are woefully inadequate when it comes to solving problems we
have. We need user-installable packages, installing packages in
different locations, support for multiple XEmacs versions on the
same machine, integration with Lisp code ("which package provides
this symbol?")