Comment 21 for bug 1267393

@adam

We *can* build and include tools binaries in the package. And in fact for many tools, we extract them from the builds, and upload them to a central distribution point (which uses the same toolchain as the ubuntu cloud images catalog -- simplestreams.

But, we don't distribute the tools binaries via ubuntu packages because they aren't installed on the a juju client user's machine. So we aren't pulling down binaries to extend what we package on the local machine -- we are pulling down binaries on the server side that the local juju client talks too.

We MUST distribute them through another mechanism because they will need to be chosen at workload deployment time based on whatever architecture, series, juju client version, and OS combination that is being targeted when that server is deployed. The key here is multi-OS support, we need to be able to support other unix and non-unix OS's, and we want one, standard code path for everything.

The local juju client package is not the right place for tools. This has nothing to do with hiding anything, and our prefered mechanism is to create the binaries in the archive -- where we don't we create them in PPA's now, and we will document a secure process for building them for non Ubuntu OS's as we start officially supporting those OS's next cycle.

We use simplestreams because we already have code that uses simplestreams to select the right architecture, series, and version for cloud images -- so we are re-using that same functionality to allow us to fulfill our multi-platform mandate in a sane way.