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 proposa
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 seeme
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 duri
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:
> S
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
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 r
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 XEma
eral emacsen.
In cases like 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 generati
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
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 c
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
11 matches
Mail list logo
