Re: Update on distro bootstrapping with Guix

[Ludovic Courtès]

Simon Josefsson <address@hidden> skribis:

> address@hidden (Ludovic Courtès) writes:
>
>> All in all, from experience with NixOS, while security upgrades are more
>> demanding on Nix-based systems, they are not much of an issue in
>> practice.
>
> Thanks for explaining.  However I don't see how a locally built binary
> would fit into this?  They would either be insecure or not work after an
> OS upgrade, wouldn't they?  Since they refer to libraries in paths that
> no longer exists.  Or am I missing something?

Nix & Guix are transparent source/binary deployment tools.  Suppose you
have a Guix recipe to build a specific GnuTLS version, with a specific
libtasn1, a specific GCC, etc.  If a pre-built binary that corresponds
*exactly* to that recipe is available at the build farm, then it is
downloaded; otherwise, the package gets built locally.  So whether it’s
locally-built or not doesn’t matter.

Perhaps you were asking about previously installed packages linked
against a vulnerable libc, for example?  Again, those packages remain
vulnerable, until you upgrade to the new version, that links against the
fixed libc.

(Similarly, in Debian, packages remain vulnerable until you run “apt-get
upgrade”.)

> Does guix have some mechanism to handle a set of installed packages and
> their versions?  I'm thinking that you'd might want to lock down the
> system to match a particular suite of tested software combinations, but
> receive security upgrades for those packages, but not receive other
> upgrades and certainly not receive the latest version of every package.
> This would match how normal OS releases work.  The important thing is
> that the set of installed packages should come from some server
> somewhere, manually selected by the contributors to the project, and
> that the list can be modified over time and updated automatically by
> machines.

With Guix & Nix, the distro is a set of package build recipes, including
information to combine them together.

Switching to a new glibc release in the distro consists in updating the
build recipe of glibc.

So, you can have several branches of the distro: “trunk”, which would
correspond to “unstable” or “experimental” in Debian parlance, and
“stable”, which would only get security updates.

In fact, this is exactly how Nixpkgs has been managed over time: when a
possibly destabilizing update is made (new major GCC or glibc version,
new X library versions, new Qt version, etc.), a topic branch is made,
which allows us to see its impact on all the packages of the distro, as
it gets built on hydra.nixos.org.

Most users obviously keep using “trunk”, which is the “stable” branch in
Nixpkgs, and thus are not affected by the experimental upgrade going on
in the other branch.

> On the feasibility side, I would have higher hopes for something that
> were able to re-use the work that has gone into dpkg/rpm packaging
> because that would re-use of existing packages, to get a usable system
> rapidly.  Maintaining build descriptions for those 20.000+ free software
> packages out there is a huge amount of work.

Yeah.  I think that Guix’s approach is not too unreasonable either, for
two reasons:

  • Guix is interoperable with Nix, so one can install Nixpkgs with Nix,
    and they coexist with packages installed with Guix (right now,
    Nixpkgs provides 10,250 source packages);

  • package descriptions in Guix and Nixpkgs are high-level, and very
    close to each other; in addition, Nix can emit an XML representation
    of its AST, which will allow simple build recipes to be
    automatically or semi-automatically converted to Guix;

  • most workflow issues arising from this new model have already been
    addressed by the Nix community.

> Personally, I'd be happy to use something based on Debian/Ubuntu but
> profiled for GNU [1].  But I support all work that leads to more
> technically interesting GNU-free OSes.

Yeah.  I find support for parallel installations, complete dependency
descriptions, per-user installations, atomic upgrades and rollback, and
so on pretty compelling [0].  It’s a huge technical gap IMO.

Hope this clarifies things a bit!

Ludo’.

[0] More details at <http://nixos.org/nix/>.