[Nix-dev] Re: [Nix-commits] SVN commit: nix - 22529 - raskin - in nixpkgs/trunk/pkgs: development/interpreters/perl-5.10 development/interpreters/python/2.6 development/libraries/avahi development/libraries/cairo development/libraries/consolekit development/libraries/enchant development/libraries/freetype development/libraries/libjpeg development/libraries/libxml2 development/libraries/openssl development/libraries/zlib development/tools/misc/gnum4 lib os-specific/linux/hal servers/pulseaudio tools/networking/curl top-level

Marc Weber marco-oweber at gmx.de
Thu Jul 8 16:07:03 CEST 2010


Excerpts from Eelco Dolstra's message of Thu Jul 08 15:39:35 +0200 2010:
> On 07/08/2010 03:25 PM, Michael Raskin wrote:
> > -{ stdenv, fetchurl }:
> > +{ stdenv, fetchurl
> > +  , ...}:
> 
> Urgh, please don't do this.  (I think this has come up before.)  It's very ugly
> to arbitrarily add "..." to some packages just because they happen to be
> involved in a "deepOverride".  It weakens the precision of the function
> interface definition.

That's what I'd like to change on this list (if I can?). There are
two interests:
MichaelRaskin wants some deepOverride features to provide packages some
of us might want to use.
Eelco Dolstra doesn't want this implementation - however there is no
hint which way should be chosen instead. What should MichaelRaskin do
now?
  - revert ?
  - ignore this wish from Eelco Dolstra ?
  - propose something else (which is probably more complicated. If it
    wasn't he'd comitted it that way)
  - create a custom branch ?

I think a reply "Please don't" should also include some hints helping
the committer to choose one of the options listed above.

Maybe its only me who doesn't know how to cope with such a reply which
just says "No" or "please don't"

The easiest option is "ignore". However I feel that could lead to "Don't
discuss at all".

I think the deep override implementation by Michal Raskin is the only
way to keep more up to date packages and older packages within the same
nixpkgs repo and without causing too much extra work compared to achieve
the goal making a newer package compile.

.. my 2 cents on this ..

Marc Weber



More information about the nix-dev mailing list