[[!comment format=mdwn
 username="joey"
 subject="""comment 1"""
 date="2015-10-16T16:05:44Z"
 content="""
This is already implemented in propellor, but is currently only used
when the remote host doesn't have git installed and apt fails to install
it. I've used it for converting non-Debian systems to Debian eg.
See Propellor.Spin.sendPrecompiled

Going beyond what's there now is not a feature I need myself, and not a
priority for me to implement, but I can help to some extent if you're going
to work on it.

Both the controller and host architecture matter of course in determining
whether it will work. For example, an i386 controller will produce a
propellor bundle that works on amd64. An amd64 controller's bundle *may*
work on an i386 host, but only if its hardware and kernel happen to support
64 bit. The simplest solution I can think of is to send the precompiled
binary over to the host and check if it runs there before replacing any
older propellor binary with it.

The other question is, how to tell propellor when to use this mode. Some
ideas, which build on each other.

* --spin --precompiled

* Add a `precompiled` property to the host that needs precompiled propellor.
  The property can set Info, which --spin can look at to know if it needs
  to use sendPrecompiled for this host, without needing --precompiled

* Could also add a property that says a host is the controller for other
  hosts. So, anytime propellor is run on the controller host, it
  automatically spins the other hosts. And if the hosts it's spinning
  have the `precompiled` property, the controller will honor it.

Note that propellor's cron job will probably fail on a precompiled host,
since even if it manages to pull changes from the central git repo
(unlikely as a precompiled propellor currently isn't set up as a git repo),
it can't locally compile them.

So, in order to have a centralized repository with precompiled hosts,
you need a controller that can handle sending the updated builds of
propellor to them.
"""]]
