Re: Adoption of Nix?
On 02/23/2013 07:45 PM, Daniel Hartwig wrote:
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 was just trying to not start anew, but rather revisit.
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.
Right, and that's why I proposed manipulating Apt and Dpkg such that
they can understand and behave within a system with multiple installed
versions managed in various places.
To be clear, I don't think Nix is salvageable. That's why there was a
big run about the whole project running off into la-la land with the
ferrets. Instead I want dpkg itself to:
1) Competently handle situations where multiple versions of a package
may be installed and managed in a Nix-like way; and
2) Expose a programming API so that someone can later provide a
plug-in to extend dpkg with Nix-like behavior
The existing software out there for this should never, ever be used. It
is terminally broken.
I think (1) and (2) would be a more minimal task, and would also provide
a better framework for full multi-arch support (something somewhat
lacking in dpkg last I checked, whereas RPM seems to have an infectious
disease where x86_64 archs one day install a .i686 package for some
unknown reason and then begin installing .i686 EVERYTHING whenever you
install any package... okay, so THEY have working multi-arch support, I
guess).
That would appropriately increase aji and leave open many possibilities for
the future.
aji?
Available entropy such that the flexibility to follow new possibilities
and gain a stronger position continues to exist.
The goal is to open a possibility, without imposing a new constraint.
Reply to: