gnu-system-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Update on distro bootstrapping with Guix


From: Ludovic Courtès
Subject: Re: Update on distro bootstrapping with Guix
Date: Thu, 11 Oct 2012 22:42:01 +0200
User-agent: Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux)

Simon Josefsson <address@hidden> skribis:

> address@hidden (Ludovic Courtès) writes:
>
>> Simon Josefsson <address@hidden> skribis:
>>
>>> address@hidden (Ludovic Courtès) writes:

[...]

>> (Similarly, in Debian, packages remain vulnerable until you run “apt-get
>> upgrade”.)
>
> I meant something I build locally as a non-root user on the system, a'la
>
> wget http://ftp.gnu.org/...
> tar xfa ...
> cd ...
> ./configure && make
>
> that will link to vulnerable libraries until it is rebuilt, wouldn't it?

Right.

> That doesn't happen on a Debian/Ubuntu system, so it is a difference.
>
> This could be solved by having a tree with symlinks to shared libraries
> which stay the same across security updates.  E.g.,
>
> /lib/libfoo.so -> 
> /nix/store/r8vvq9kq18pz08v249h8my6r9vs7s0n3-libfoo-1.0/lib/libfoo.so
>
> Has an (optional) symlink approach been considered, which would also
> lead to more FHS compatibility?

Actually, each user as a forest of symlinks under ~/.nix-profile
pointing to packages installed by the user.

So in the above example, you would typically have $HOME/.nix-profile/lib
in $LIBRARY_PATH, and you would link against libfoo from there, and the
resulting binary would have a RUNPATH pointing to
$HOME/.nix-profile/lib/libfoo.so.

[...]

>> 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.
>
> This sounds good.  Possibly you'd want to name the stable branches,
> since over time you may have several of them maintained concurrently.
> Compare how Ubuntu supports many stable releases at the same time.  For
> some machines, I would not ever want software upgrades, but still be
> interested in security upgrades.

Yes, sure.

[...]

>> 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.
>
> Right, it is revolutionary, and there is some disadvantages with that
> since it requires that everything adapt to the new model.  Minimizing
> those costs will make it appear evolutionary and more people might
> switch...

Yes, but there’s no free lunch, if I may.  ;-)

The Mancoosi EU FP research project has tried to work toward providing
some of these features on top of “regular” distros in its WP3 [0].  A
deliverable from May 2011 [1] mentions modified APT and RPM versions
supporting transactional upgrades and rollback, but I haven’t found
traces of production code or such.

Actually, Nix’s storage model is can actually be thought of as an
evolution of GNU Stow’s, something many are familiar with.  :-)

Thanks,
Ludo’.

[0] http://www.mancoosi.org/work/#wp3
[1] http://www.mancoosi.org/reports/d3.3.pdf



reply via email to

[Prev in Thread] Current Thread [Next in Thread]