[Pkg-javascript-devel] npm debian package

Isaac Schlueter i at izs.me
Fri Oct 7 18:23:43 UTC 2011


>> then `npm install npm -g` will
>> result in two copies of npm installed, which is confusing to users.
>
> That is right and this is what a debian user would expect to happen.
> http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.2
> And it exists for a good reason : what the user put in /usr/local is up
> to him.

Fair point.


>> special case for when
>> prefix==/usr.  It's inelegant, to say the least.  Special-casing based
>> on the location of the npm executable is even worse.
>
> What's inelegant is having /usr/etc/npmrc.
> You cannot fit in the same scheme what goes in /usr/local and what goes in / :
> /usr/(bin|lib|share)/npm /etc/npmrc
> /usr/local/(bin|lib|share) /usr/local/etc/npmrc
> The hierarchy is just not the same when prefix is changed, please acknowledge that.

Why is the hierarchy "just not the same" when the prefix is changed?
I don't understand that at all, and as far as I can tell, several
other programs do exactly the same thing that npm does.  I have a
/usr/etc on both of my Linux systems, one of which is Debian, and the
other Ubuntu.  Both of them contain configuration information for
various programs.  What's it intended to be used for?

It IS inelegant (though, perhaps an inelegance in the dogma of FHS,
which we cannot correct at this point in history), because it means
that I can't just say that the globalconfig and globalignorefile
configuration parameters default to {prefix}/etc/npm{rc,ignore} any
longer, but have to explain in the documentation that if you're using
the prefix of /usr then it'll actually put those config files a level
up above the prefix.  The guarantee that "npm never does anything
outside its prefix setting or $HOME" is then gone.

Because we're talking about the location of a configuration file, we
can't as easily override it without using a shim.  You could build and
install npm to /usr/share/npm, and then write this to /usr/bin/npm:

#!/bin/bash
npm_config_globalconfig=/etc/npmrc /usr/share/npm/bin/npm "$@"

since environmental configs override defaults, globals, and
userconfigs.  Then, you can put any *other* configs that you want to
default differently into the /etc/npmrc file:

prefix = /usr/local
globalignorefile = /etc/npmignore

This install target, shim, and globalconfig setting would allow a user
to use npm to install a new version of npm, and then remove their
npm-installed npm (in /usr/local) to go back to using the
debian-installed one.  (Assuming their path is something like the
standard "/usr/local/bin:/usr/bin:/bin".)

The hazard there, however, is that the npm-installed npm will default
to a prefix of /usr, since node is installed in /usr/bin, and then
we're right back in the same spot!

This definitely will happen.  Users come into the node irc room, and
ask how to update npm.  Not realizing that they've installed it using
apt-get (or homebrew, or macports, or yum, or whatever) rather than by
following the instructions in the readme file, or because they need a
fix which has not yet made it into the official debian ppa's, we'll
tell them to have npm update itself, and it will lead to this odd
broken state.

How is this handled with other platform package manager dpkgs?



More information about the Pkg-javascript-devel mailing list