Failed to install on Ubuntu 14.04 trusty

[LinusU]

Preparing to unpack .../nodejs_0.10.31-1chl1~trusty1_amd64.deb ...
Unpacking nodejs (0.10.31-1chl1~trusty1) over (0.10.25~dfsg2-2ubuntu1) ...
dpkg: error processing archive /var/cache/apt/archives/nodejs_0.10.31-1chl1~trusty1_amd64.deb (--unpack):
 trying to overwrite '/usr/share/man/man1/node.1.gz', which is also in package nodejs-legacy 0.10.25~dfsg2-2ubuntu1
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Processing triggers for man-db (2.6.7.1-1) ...
Errors were encountered while processing:
 /var/cache/apt/archives/nodejs_0.10.31-1chl1~trusty1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

nodejs-legacy provides a symlink from /usr/bin/node to /usr/bin/nodejs which is very helpful if you are used to Node.js being installed as node.

I think that the correct solution is to mark this package as conflicting with nodejs-legacy and, if nodesource is providing the symlink, mark it as replacing.

[LinusU]

I fixed the problem by first removing nodejs-legacy and then doing apt-get distupgrade again, which replaced my installed version of nodejs with the one from nodesource.

[rvagg]

thanks for reporting this @LinusU, we're figuring out the cleanest way to deal with this and will have a fix in soon(ish), there is likely a similar problem on debian too

[leviwheatcroft]

yep same problem on debian, I've removed nodejs & nodejs-legacy, then apt-get dist-upgrade, but I still get the same error when I try to reinstall nodejs-legacy

[astesin]

Ubuntu once again. Tried to follow instructions from here: https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager#debian-and-ubuntu-based-linux-distributions and got:

Reading package lists... Done

Confirming "trusty" is supported...

+ curl -sLf -o /dev/null 'https://deb.nodesource.com/node/dists/trusty/Release'

Your distribution, identified as "trusty", is not currently supported, please contact NodeSource at https://github.com/nodesource/distributions/issues if you think this is incorrect or would like your distribution to be considered for support

$ uname -a
Linux myhostname 3.13.0-36-generic #63-Ubuntu SMP Wed Sep 3 21:30:07 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

it's Ubuntu 14.04

UPD. Solved. I tried the command as provided at the site, and correct way is just sudo to root shell and run setup from there. Maybe this has something to do with recent bash patches?

[rvagg]

Are you behind a firewall or something that's blocking curl access to https://deb.nodesource.com @astesin? It shouldn't be saying that "trusty" isn't supported but it's saying that because the curl command shown returns a non-zero exit code. Plus, I have no idea how you managed to solve this by doing it as root, it should have the same effect.

Standard way of running it is as root using sudo though:

curl -sL https://deb.nodesource.com/setup | sudo bash -

[terkiterje]

@astesin take a look at issue #20 if you are behind a proxy, like in many corporate environments. Basically try to add -E to the sudo, or run the setup script in the pull request #22 without sudo. The latter should also produce the error message from the curl call failing allowing you to pinpoint the issue if it's not the proxy issue

[pdmurray]

I was having the same error as @astesin on Ubuntu 14.04. I'm behind a corporate proxy and I got it to work by using sudo -E as @terkiterje suggested.

One issue I had- I was only exporting $http_proxy set to my proxy host but not $https_proxy. Once I added that it was totally working with the following command:

curl -sL https://deb.nodesource.com/setup | sudo -E bash -

[rvagg]

sudo -E is now on the readme

[n0mer]

for me - the underlying problem was the following:

root@669a56e7c4c4:/# curl -Lf https://deb.nodesource.com/node_0.12/dists/trusty/Release
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

Installing the package ca-certificates solved the problem (as it was suggested by @MichaelBitard in #42)