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.mo...@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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/can3verdqjuemc7c87dzechrv9az7t+kwupa4b+59q0cjyh3...@mail.gmail.com
