[Pkg-javascript-devel] npm debian package

[Jérémy Lal]

On 07/10/2011 20:23, Isaac Schlueter wrote:
>>> 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?

Humanity... because it should have been IMO :
/usr/local/usr/bin
/usr/local/usr/lib
/usr/local/usr/share/man
/usr/local/etc
mimicking what happens at /

> 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 means you install programs manually from time to time,
or you found a bug in a debian package. Please report :)
On my debian laptop/pc/servers i get :
ls: cannot access /usr/etc: No such file or directory

> 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 is exactly what current (very outdated, don't mention it) npm debian package does.

> 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.

What i did to prevent that was forbid npm global self-update.
With the current discussion, i was hoping to find a better compromise,
which would result in allowing npm self-update (if it can honor /etc/npmrc, as you
understood very well).

> How is this handled with other platform package manager dpkgs?

gem update --system
ERROR:  gem update --system is disabled on Debian, because it will overwrite the content of the rubygems Debian package, and might break your Debian system in subtle ways. The Debian-supported way to update rubygems is through apt-get, using Debian official repositories.
If you really know what you are doing, you can still update rubygems by setting the REALLY_GEM_UPDATE_SYSTEM environment variable, but please remember that this is completely unsupported by Debian.

Jérémy.