[Pkg-javascript-devel] npm debian package

Isaac Schlueter i at izs.me
Fri Oct 7 21:40:30 UTC 2011


On Fri, Oct 7, 2011 at 12:37, Jérémy Lal <jerry at edagames.com> wrote:
> 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 /

But that's not what happens at /.  At /, you have:

/bin
/sbin
/lib
/etc

And in usr, you have:

/usr/bin
/usr/sbin
/usr/lib
/usr/etc (ok, not this one on debian, you're saying)

and in /usr/local, you'd have:

/usr/local/bin
/usr/local/sbin
/usr/local/lib
/usr/local/etc

/ is for the base system, /usr is for the distro/system package
manager, and /usr/local is for the user.

Why not just do what homebrew does, and print out a caveat that npm is
not debian-approved, and point them at the install instructions?  It's
literally one line.

> It means you install programs manually from time to time,
> or you found a bug in a debian package. Please report :)

Apparently this is because I use couchdb 1.1, and their installer just
takes a prefix and tacks the standard folders onto it (etc, bin, lib.)


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

Exactly.  And people whine and complain to me occasionally, and I tell
them to install it the way it likes to be installed, using the
installer that I wrote and bundle with npm specifically for the
purpose of installing npm.


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

That's hideous.  It would be better to just not distribute a rubygems dpkg, imo.


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

So, anyway, we all have strong opinions about this stuff, and maybe
it's best to just assume that we can't convert one another, and maybe
get creative :)

The problem is that you can't override the global config except from
the userconfig, env, or cli, and those mechanisms are proving to be
inadequate.  So how about this proposal?

I add another config file, located in the same folder as npm.js (ie,
in your case, /usr/lib/node_modules/npm/npmrc or something.)  Could
call it "builtinconfig" or something.

This file would be lower priority than any other config file, but
higher priority than the defaults.

Whenever npm fetches and unpacks the npm package, it will copy its
builtinconfig file into that new copy of npm.  This way, it will
survive self-updates without wrecking the system.

Then, your dpkg scripts can run `./configure --prefix=/usr/local
--globalconfig=/etc/npmrc ... && make install`, and I'll happily help
debug issues, because it'll all be using the published interfaces that
I designed and take ownership of.

How does that sound?  It's arguably more magical than the /usr/etc ->
/etc switch, but I think it also is a lot more versatile for the next
package manager that comes along and has different opinions than dpkg
or npm, and feels like less of a compromise and more of a win-win.



More information about the Pkg-javascript-devel mailing list