[Nix-dev] Beginner question about external recipes

[Bryce L Nordgren]

On Tue, Dec 6, 2011 at 4:36 AM, Michael Raskin <7c6f434c at mail.ru> wrote:

> >For context, my near term interest is to control an ArchLinux environment
>  >1] rollback capability
> >2] better closure determination for "point upgrades" (individual
> packages).
> >3] Automatic rebuilds of "customized" packages.
>

I cannot understand what you want to do.
>
> Should Arch build scripts run unmodified?


Yes.


> In this case, how do you
> untangle the effects of various packages registering their mime-types
> in /usr/share? If you want to parse the recipes, you will have to
> fix some underspecification of expressions anyway.
>

The Arch package manager also runs unmodified, but deploys into a
chroot...a chroot constructed as a "generation" of a "profile" of an
external environment.  Ergo, software deployed to any of these chroots
"sees" the environment it expects to "see".  The artifacts deposited in the
nix store would be the built packages: not usable directly where they are,
but perfectly capable of being merged into a working environment. As far as
nix is concerned, these are data items, not running code.

Nix manages the chroot environment. Nix ensures that upgrades are atomic
and can be rolled back. Nix is the thing that runs the arch package
manager, after it has determined an acceptable target closure. If nix
determines that the upgrade would modify (upgrade) software which is needed
by installed packages (one of the thorns in my side), it can recompile the
dependent packages against the upgraded libraries. This behaviour already
seems to be implemented in nix (nix-env --upgrade --eq), but while this is
a convenience for good management of a content addressable nix store, it's
necessary for a "single environment deployment".

In general, I would say that the official Arch packages have a high level
of purity (due to the use of a chroot when building). Problems stem from a
shortage of "precision" in package dependency specification. Precision has
to do with uniquely identifying a specific instantiation of a source
recipe--the lack of which is a common shortcoming in other packaging
systems. If nix has access to instance identifiers, it should be capable of
determining which packages need to be rebuilt.

Two specifics from this email:
1] To ensure that upgrades are atomic, nix must manage multiple
environments, like it manages multiple user profiles with multiple
generations. These will be whole chroot environments and not just
directories of links, however. They must appear to be copmpetely
independent copies, but may be implemented with a copy-on-write filesystem.
2] Identification of a particular instance may consist of (pkgname,
dependencies, packager, build timestamp). The external source recipe does
not have "options", so there's no need to include a list of them.

Similar concepts should also apply to other external packaging systems.

I hope I'm starting to use nix terminology correctly. ;)

Bryce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20111206/32ea9ca1/attachment.html