-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/04/14 15:18, Matthias Klose wrote: > - Stop bundling every source in juju-core. I think the dh-golang helper, albeit with golang gc as the default, is now sufficiently developed to support this for juju-core; however this ties heavily into how jujud tools are distributed as we could end up with a situation where the jujud built in the Ubuntu archive != jujud built for distribution in simplestreams. I've been thinking about this over the last few days and I can't see a route to main for juju-core unless the jujud bits are always built in-archive - these could still potentially be distributed via simplestreams to support the versioned tools approach that juju takes - - probably worth covering how this works for the benefit of others. When a user bootstraps and environment, a tool version selection is made based on the best compatible tools for the client version - so a juju client at 1.17.7 would always pick from 1.17.x; the environment sticks to this version for all new units even if there is a new 1.17.x release - the administrator of the environment initiates an upgrade to this new version using juju: juju upgrade-juju myenv at which point the jujud daemons on the service units pickup the new version, perform any upgrade steps and restart with the new version of the binary. This allows the juju-core development team to have direct control over what happens during an upgrade and how its orchestrated across a running environment. I think this is a unique feature which is extremely hard to address in the packaging space and is very useful for end-users. However this does complicate updates of any kind; thinking in the context of a security update in a world where all juju-core dependencies are in separate packages and juju-core is still statically linked, the security update in the dependency requires a rebuild of juju-core - however this must bump the version of juju-core otherwise its not possible to effectively distribute new tools via simplestreams. Right now addressing an update/bug/security fix has to be done in-conjunction with juju-core upstream (as all dependencies are currently bundled in the source tree) so that tools and distro binaries stay in sync (hence the need for a MRE for juju-core which I will be submitting soon). Patching the distro package fixes issues for those using the local provider or using --upload-tools, but not 'normal' users consuming tool binaries from simplestreams. I guess if juju understood how to interrogate package versions from the archive, it might be possible to always build a version namespaced binary package, e.g. juju-core-1.17.8, so that the archive would retain a history of juju-core versions, allowing juju to pick a) the current version it needs and b) upgrade to a new version if available. - -- James Page Ubuntu and Debian Developer