Re: Adoption of Nix?
Hello
Just some quick notes related to this, without jumping in to the
discussion (yet?).
On 24 February 2013 01:28, John Moser <John.r.moser@gmail.com> wrote:
>
> Daniel Burrows <dburrows <at> debian.org> writes:
>
>>
>
> Note: I'm not subscribed to the list, and pulling this old thread through
> Gmane; please CC directly to me.
>
> The purpose of this is to cross-examine Daniel's thoughts and bring new
> thoughts to the surface.
Daniel Burrows is not active in Debian for some time, and should perhaps
not be expected to partake in the resumed discussion.
> I'll put the main proposal up front:
>
> I feel that being able to install multiple system profiles with dependency
> resolution is a good feature--i.e. the feature of Nix that lets one program
> see /usr/lib (or what is effectively its /usr/lib) as something entirely
> different from what another program sees.
>
> It shouldn't be a core, absolute feature.
>
> Instead, I think it's best to find the least-effort way to modify dpkg so that
> it:
>
> 1) Can handle running on a system managed like this; and
> 2) Provides an API to extend dpkg/apt to function this way
>
> In other words, add the capability for a plug-in that changes the way packaged
> files are stored and managed, and let somebody else hook up to the glue code
> and make it happen. Don't break Debian for the rest of us.
Nix operates fairly indepently of the underlying system. There is no
pressing need for dpkg–nix integration at this point, indeed, that is
a can of worms. To briefly illustrate:
Debian packages are each built with specific configurations (enabled
features, etc.), call this a build profile. When one Debian package
declares a dependency on an other, it is with the implicit knowledge
that a particular build profile or feature set is provided.
Nix allows multiple builds of the same package–version to be installed
with different, and arbitrary build profiles, and allows other
packages to depend on exactly the features they require in the
profile.
Without a map from Debian package–version to build profiles, there is
no way to reliably know whether a particular Nix build either
satisfies a Debian package dependency, or has one of its dependencies
satisfied by an installed Debian package. For this reason, I believe
it is not viable to integration Nix and dpkg, and the two should be
thought of as independent systems: dpkg has installed your main (or
base) system, and a user is free to layer any Nix packages on top.
Nix packages installed in per-user profiles will not generally
interfere with Debian packages.
Unfortunately, there will be some waste as Nix duplicates a small set
of base dependencies (gcc, etc.). Though you could avoid this with a
nix-base package that depends on the equivalent Debian packages and
provides Nix the information that certain
package–version–build-profiles are installed.
>
> That would appropriately increase aji and leave open many possibilities for
> the future.
aji?
>
> (For what it's worth, I don't like the direction Nix went in. Stick to
> managing packages and system layout; Nix goes all the way out to managing your
> configuration file CONTENTS, which among other things makes it completely
> useless in serious production cases--Nix wants to live in its own, rigid little
> world and not play well with others at all).
>
Right. A good reason to keep it separate.
>
>> Hi there. As I'm sure everyone knows, I'm not exactly unbiased here
>> since I've done a lot of work on the apt system (although nix looks more
>> like a replacement for dpkg).
Since this old discussion there is now also Guix
<http://gnu.org/software/guix/> constructed on top of Nix that
provides some nicer interfaces. Think of it as operating at the apt
level, I suppose.
Thats all for now.
Reply to: