This issue is fun. Firstly, it does impact the upstream build. I reproduced
our Homebrew build outside of Homebrew, and the symlinking the symlinks
breaks there.
The way npm's `make install` works is to install everything into the
prefix specified, in this case libexec/npm, and then it creates symlinks
from libexec/npm/lib/node_modules/npm/man/man*/npm* to libexec/npm/share/man*/npm*.
For some reason, those symlinks break, both inside and outside of Homebrew, albeit
slightly differently. Outside of Homebrew they break in the symlinking the
symlinks stage. Inside of Homebrew they break in `make install`. Who even knows why.
This issue also doesn't reproduce constantly.
Sometimes it ["just works"](https://farm3.staticflickr.com/2066/5807458526_dc54025065_z.jpg).
Exactly what variables cause it to work and what causes it to break, who knows. I looked into
different shells, different versions of npm, different OS X versions - None of it seemed to matter.
The workaround is just to symlink the solid, tangible manpages that exist in
libexec/npm/lib/node_modules/npm/man/man* rather than symlinking the symlinks
that exist in libexec/npm/share/man/*.
As reported in https://github.com/Homebrew/homebrew/issues/39823#issue-77146790
in some cases the `make install` stage of `npm` seems to symlink inside the buildpath,
even though we're setting the prefix to libexec/npm and have encountered no other
issues with retention of build paths.
The problem *seems* to be that ln_sf itself is storing the paths. If I do it outside
of Homebrew, I get this:
```
ln -sf share/man/man1/* /Users/Dominyk/Downloads/package/TEST1/hmm/share/man/man1
ls -l /Users/Dominyk/Downloads/package/TEST1/hmm/share/man/man1/npm-config.1
/Users/Dominyk/Downloads/package/TEST1/hmm/share/man/man1/npm-config.1 -> share/man/man1/npm-config.1
```
Which obviously creates dead symlinks in /Users/Dominyk/Downloads/package/TEST1/hmm/share/man/man1/*.
If I switch over to using GNU's `ln` instead of OS X's default, and use this command instead:
`gln -sfr share/man/man1/* /Users/Dominyk/Downloads/package/TEST1/hmm/share/man/man1` I get:
```
/Users/Dominyk/Downloads/package/TEST1/hmm/share/man/man1/npm-config.1 -> ../../../../../man/man1/npm-config.1
```
And it seems to work. To my knowledge, BSD `ln` doesn't contain the relative option.
Closes#39823Closes#39947.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
`npm` believe they’ve fixed the `npm update -g` command upstream, and
having tried for an hour today to get my Node installation to break
itself via `npm` it looks like they have.
This ultimately resolves#34413 and related issues, for good, hopefully.
Closes#38717.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
Kinda hate doing this so soon after the last Node release, but npm has
disclosed and fixed a couple of reasonably serious security issues in
the 2.7.5 release and we should push that.
See: https://github.com/npm/npm/releases/tag/v2.7.5Closes#38350.
Signed-off-by: Xu Cheng <xucheng@me.com>
Both 2.6.1 and the consequent 2.7.0 ended up being really quite major
npm releases, with some nifty new features, not least:
*drumroll* the problem where doing `npm update -g` would completely
murder your entire npm installation has been significantly reduced. Not
completely, but significantly.
Other stuff:
* New documentation pertaining to the above. If you’re super-interested
in running wild with the `npm update -g` command, give the new docs a
glance over first.
* A change to the handling of node-gyp which could make handling iojs
in Homebrew a less painful situation for everyone involved in the near
future.
* Minor internal deps updates.
Revision for the whole making it much harder to kill off your own npm
installation with the `npm update -g` command.
Closes#37443.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
Personally, I’d be content to keep the dep as recommended, but it’s
possible the big red warning on the different build standards is making
people jumpy, and there are use cases where the `icu4c` dep does
interfere with certain usage, so I’ve partially reverted the direction
I took in the Node PR the other day by making the new ICU capabilities
optional.
Also added a caveat for the benefit of clarity, and hope more people
complain to Node upstream to fix the real root cause of the problem
here and make life for packagers a little easier.
Closes#36712.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
Shoot me in the arm and colour me surprised, Node 0.12 has landed
stable.
Also bump npm to 2.5.1 - Although marked pre-release by upstream this
is the npm version shipped in this Node release, and currently in iojs
as well, and npm is actively nudging people into deliberately jumping
over the normal release schedule just for once, so following that lead
here.
I’ve also taken the chance to simplify the formula quite a bit,
removing the increasingly complicated devel/head/stable logic and
meshing it back into one easier block. The icu4c dep lands as
recommended because Node upstream are shipping binaries with that
support (in English) available. OpenSSL remains optional, but is moved
to general availability rather than just devel for the sake of
simplification and having it optional everywhere causing no harm.
Deps may need rebuilding. I’m hoping the bot is kind enough to check
the bottles of the formulae that have them, but I’ll do a general
double check ASAP.
Closes#36608.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
Misty De Meo
BrewTestBot
Christian Moritz
Bret Comnes
Mike McQuaid
David Smith
Dominyk Tiller
Xu Cheng
Tim D. Smith
Brandon Mills
Nikolaus Wittenstein
Vladimir Agafonkin
