Hi,
On 20/11/12 06:26, Marc Weber wrote:
If broken builds are the problem, can't we just make sure bash is the
default shell for builders?
I mean exporting SHELL properly and using bash to start the build
scripts
... which is exactly what stdenv has done since pretty much forever:
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
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
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
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
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
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
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
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
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
Hi,
On 03/11/12 15:24, Ludovic Courtès wrote:
A common problem for people trying to use Nix/Nixpkgs/Guix on non-NixOS
distros, especially Debian derivatives, is that their /bin/sh is not
Bash. On Debian and derivatives, it’s a symlink to /bin/dash.
When building without a chroot, things
Hi,
Eelco Dolstra eelco.dols...@logicblox.com skribis:
On 03/11/12 15:24, Ludovic Courtès wrote:
A common problem for people trying to use Nix/Nixpkgs/Guix on non-NixOS
distros, especially Debian derivatives, is that their /bin/sh is not
Bash. On Debian and derivatives, it’s a symlink to
Hi Ludovic,
[Things] eventually fail because stdenv, and sometimes build systems,
assume that /bin/sh is Bash.
maybe that is a bad assumption? Wouldn't it be nice if our stdenv worked
with any POSIX shell, not just Bash?
Take care,
Peter
___
Hello!
A common problem for people trying to use Nix/Nixpkgs/Guix on non-NixOS
distros, especially Debian derivatives, is that their /bin/sh is not
Bash. On Debian and derivatives, it’s a symlink to /bin/dash.
When building without a chroot, things eventually fail because stdenv,
and sometimes
A common problem for people trying to use Nix/Nixpkgs/Guix on non-NixOS
distros, especially Debian derivatives, is that their /bin/sh is not
Bash. On Debian and derivatives, it’s a symlink to /bin/dash.
When building without a chroot, things eventually fail because stdenv,
and sometimes build
Hi Michael,
Michael Raskin 7c6f4...@mail.ru skribis:
I have some basic-chroot.nix, which is what basics I need to do Nix
builds and look at simple problems comfortably.
It is literally:
let nixpkgs = import nixpkgs {}; in with nixpkgs;
symlinkJoin chroot-system [
nixUnstable
Hi Michael,
Michael Raskin 7c6f4...@mail.ru skribis:
I have some basic-chroot.nix, which is what basics I need to do Nix
builds and look at simple problems comfortably.
It is literally:
let nixpkgs = import nixpkgs {}; in with nixpkgs;
symlinkJoin chroot-system [
nixUnstable
Hi,
Michael Raskin 7c6f4...@mail.ru skribis:
[...]
I was thinking that, instead of just bind-mounting /bin, we could have
at least a nix-daemon option that would allow the host code to specify
which file /bin/sh should point to. Even better would be to have an
additional ‘derivation’
So, I guess there would be a configuration option (marked as dangerous
and/or impure) to override what is taken from external environment for
a normal chroot build (ideally, nothing — maybe it is possible to use
even fake proc?).
What I had in mind was more an extension of DerivationInputs.
19 matches
Mail list logo
