Re: [Nix-dev] run-time dependency missing in cabal-install

2012-11-09 Thread nixos cabal dummy
Need the 'dummies' fix to same problem: cabal install (and other cabal commands) says that ar is missing on a fresh nix install. ... P.S. geekosaur says this is a ghc problem, not a cabal-install??? Need 'dummies' fix, nevertheless , Also using cabal-install-0.14.0

Re: [Nix-dev] [Nix-commits] [NixOS/nixos] 70e6e1: xsession: source /etc/profile at the beginning of ...

2012-11-09 Thread Peter Simons
Hi Eelco, xsession: source /etc/profile at the beginning of the script Hm, not sure if this is a good idea. Won't this prevent child shells (e.g. konsole / xterm shells) from reloading /etc/profile (due to $__ETC_PROFILE_DONE being set)? yes, that is true. I.e., you'll have to log

Re: [Nix-dev] Dealing with non-Bash /bin/sh on non-NixOS

2012-11-09 Thread Eelco Dolstra
Hi, On 09/11/12 18:38, Peter Simons wrote: Is there a better way to approach that problem? Yes, fix builders not to rely on /bin/sh (or at least not to assume it's Bash). we should link /bin/sh to Dash instead of Bash. That would catch any implicit dependencies on non-POSIX shell

Re: [Nix-dev] Dealing with non-Bash /bin/sh on non-NixOS

2012-11-09 Thread Peter Simons
Hi Eelco, we should link /bin/sh to Dash instead of Bash. That would catch any implicit dependencies on non-POSIX shell features, What's the point of that? Breaking zillions of existing scripts for very little gain doesn't sound like a good idea to me. now I am confused. In the very

Re: [Nix-dev] Dealing with non-Bash /bin/sh on non-NixOS

2012-11-09 Thread Lluís Batlle i Rossell
On Fri, Nov 09, 2012 at 06:57:24PM +0100, Peter Simons wrote: Hi Eelco, we should link /bin/sh to Dash instead of Bash. That would catch any implicit dependencies on non-POSIX shell features, What's the point of that? Breaking zillions of existing scripts for very little gain

Re: [Nix-dev] Dealing with non-Bash /bin/sh on non-NixOS

2012-11-09 Thread Eelco Dolstra
Hi Peter, On 09/11/12 18:57, Peter Simons wrote: we should link /bin/sh to Dash instead of Bash. That would catch any implicit dependencies on non-POSIX shell features, What's the point of that? Breaking zillions of existing scripts for very little gain doesn't sound like a good

Re: [Nix-dev] Dealing with non-Bash /bin/sh on non-NixOS

2012-11-09 Thread Peter Simons
Hi Lluís, I understood from niksnut that this change could be done in a branch, without any merge to master until all (most?) works. yes, absolutely. If we have consensus in the community that this kind of change is desirable, then we should definitely do it in a branch. I'm just confused

Re: [Nix-dev] Dealing with non-Bash /bin/sh on non-NixOS

2012-11-09 Thread Shea Levy
On 11/09/2012 01:06 PM, Eelco Dolstra wrote: Hi Peter, On 09/11/12 18:57, Peter Simons wrote: we should link /bin/sh to Dash instead of Bash. That would catch any implicit dependencies on non-POSIX shell features, What's the point of that? Breaking zillions of existing scripts

Re: [Nix-dev] Dealing with non-Bash /bin/sh on non-NixOS

2012-11-09 Thread Peter Simons
Hi Eelco, What I meant was that in Nixpkgs you shouldn't assume that /bin/sh is Bash, because we obviously don't control that on non-NixOS systems. right, I completely agree. I don't understand, however, why you seem to insist that /bin/sh must be Bash on NixOS. Why do you think that's so

Re: [Nix-dev] Dealing with non-Bash /bin/sh on non-NixOS

2012-11-09 Thread Peter Simons
Hi Shea, Because (as this thread illustrates) that will break things, to almost no gain. if all scripts get fixed not to assume /bin/sh to be Bash, then there is a significant gain to users of Nix on non-NixOS hosts. Doesn't that count for something? It's one thing to test locally with

Re: [Nix-dev] Dealing with non-Bash /bin/sh on non-NixOS

2012-11-09 Thread Michael Raskin
How do you test packages locally with /bin/sh pointing to Dash on NixOS? I had no idea that's possible. # nix-build -A dash nixpkgs -o /bin/sh I think this won't work as expected - /bin/sh/bin/dash is not what we want. ___ nix-dev mailing list