Raul Miller [EMAIL PROTECTED] writes:
Say, ferinstance, that several revisions of a package are installed
and there are subtly different arguments each time. Or, that package
installation fails, is backed out, then installed then reconfigured?
Several clients or servers? Clients would
Manoj Srivastava [EMAIL PROTECTED] writes:
This will not work for packages like Gnus, bbdb, w3,
hyperbole, vm, and psgml, since the compilation requires selectively
preloading some files, or even running complex build-scripts during
the compilation of the elisp files.
Why can't they
Raul Miller [EMAIL PROTECTED] writes:
Say, ferinstance, that several revisions of a package are installed
and there are subtly different arguments each time. Or, that package
installation fails, is backed out, then installed then reconfigured?
Guy Maor [EMAIL PROTECTED] wrote:
Several
Hi,
Guy == Guy Maor [EMAIL PROTECTED] writes:
Guy Manoj Srivastava [EMAIL PROTECTED] writes:
This will not work for packages like Gnus, bbdb, w3, hyperbole, vm,
and psgml, since the compilation requires selectively preloading
some files, or even running complex build-scripts during the
Manoj Srivastava [EMAIL PROTECTED] writes:
Because the normal build process is to say make build;
And, as I just realized, this in itself could be problematic. Are we
going to add Depends: make to the emacs lisp packages that do this
in their postinst? I guess we could, but it seemed a
Hi,
Rob == Rob Browning [EMAIL PROTECTED] writes:
Rob Well, I don't see how to fix the needing files that aren't
Rob available problem (when does this happen?), but the
Rob multi-directory make process shouldn't be a problem. There's no
Rob reason the hook file for tm in Guy's proposal couldn't
Rob Browning [EMAIL PROTECTED] writes:
I think that we should have some sort of install procedure (a la
install-info) for emacs .el files.
We keep going down this route again and again - info, elisp, menu,
mime. Maybe we should generalize this?
Let's provide a system where packages could
Guy Maor [EMAIL PROTECTED] wrote:
When a provider first installed a hook, the system would immediately
run the hookfile for all clients that already registered. Then
whenever a new client registered, it would run the hookfile. The
hookfile would be run with the same arguments that the client
Hi,
Guy == Guy Maor [EMAIL PROTECTED] writes:
Guy For elisp files, it might work like this.
Guy $ register-service --help register-service --install service
Guy package [param=value ...] register-service --remove service
Guy package
Guy In the dpkg postinst: register-service --install elisp
that, it may make sense to do much of the work at
pacakge build time. Then you might be able to end up with a package
that containes all of the non-.elc stuff for each emacs, and then use
the service registration procedure and appropriate hooks to handle the
.elc generation.
I guess what I'm saying
The XEmacs team is working on unbundling much of the elisp that used
to be included. There is a new set of functions for building and
adding packages' autoloads and `customize' dependancies. I believe
(though I am not certain) that it will require there be a `temacs'
installed, and that
11 matches
Mail list logo
