Latest thoughts on user level package management

[Nick Coghlan]

On 7 June 2015 at 04:54, Colin Walters <walters at verbum.org> wrote:
> On Thu, Jun 4, 2015, at 03:41 AM, Nick Coghlan wrote:
>
>> This level would be developer components in a language and distro
>> independent format. nix is the current frontrunner in my mind, mostly
>> due to the good discussions between myself, Randy Barlow (Pulp) and
>> Domen Kožar (NixOS), and the fact that Nix already uses the model of a
>> central system-wide package store, with user and environment specific
>> views into that store (this is a much nicer architecture for auditing
>> purposes, since you can audit the package store directly, rather than
>> having to check each environment).
>
> Nix has a lot of good ideas, but I think *forcing* rebuilds of
> dependencies makes it pretty impractical for use in many
> scenarios.
>
> The example I normally use is a glibc security update
> meaning a rebuild of *everything* is just not realistic.

Yeah, the "responding to a glibc CVE" case is the one that's always
given me pause about Nix's hash-based design. The main idea I've had
on that front is to wonder whether Nix could be updated to track *two*
kinds of dependency: build dependencies, and link dependencies and
then separate the notion of rebuilding a binary from relinking it. By
default, you'd get your link dependencies being the same as your build
dependencies.

Publishing an ABI compatible update? You have to relink the world, but
you don't have to rebuild it. Breaking ABI? It's rebuild the world
time.

That's all very handwavey speculation though, and in the near term, I
think the example of Go and image based immutable infrastructure shows
us that "rebuild the world" is at least a potentially more tractable
problem in the era of being able to use cloud infrastructure for a
temporary surge in build capacity.

> The user-level package management is interesting,
> although it overlaps with:
>  - xdg-app SDKs
>  - Installing build tools as traditional RPMs
>  - Docker derivation (works OK for scripting languages, less
>    well for compiled languages with a strong build/runtime
>    dependency split)

Right, since writing this initial draft of the Aleph proposal, I've
been pondering this question, and wondering whether the
mutable/immutable infrastructure split provides a potentially useful
organising principle for some of these different approaches.

= Mutable infrastructure technologies =

* RPM
* Software Collections/Developer Toolset
* Language specific package management tools
* rolekit
* xdg-app
* long lived multi-service virtual machines and containers
* VM and container snapshots, restoration, live migration, etc

The philosophy of mutable infrastructure is "rebuilding the world is
expensive (or impossible), try to avoid needing to do it". It trades
off minimising the cost of responding to changes in low level
components like glibc for the ongoing cost of additional investment in
ensuring environments remain in an expected, consistent state.

= Immutable infrastructure technologies =

* RPM-OSTree (and Atomic Host in general)
* Nix
* ephemeral single-service virtual machines and containers

The philosophy of immutable infrastructure is "component failures are
inevitable, so automate both the process of rebuilding from scratch
and the process of detecting failures". It industrialises the process
of rebuilding and redeployment for particular scenarios (primarily
Software-as-a-Service), and favours regularly redeploying (and
auditing the deployment and monitoring process), over auditing the
deployed services directly.

When applicable, this model categorically rules out certain kinds of
problem, but its weakness is that we haven't really generalised the
model beyond web-based SaaS at this point. (OTOH, that's a "niche"
which has proven to be an incredibly effective approach for delivering
centrally managed cross-platform services, so "only" working well for
web-based SaaS isn't much of a criticism - it just means that the
immutable infrastructure tech complements the existing mutable
infrastructure tech, rather than displacing it)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia