[Pkg-javascript-devel] npm debian package

[Jérémy Lal]

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

That sounds perfect, thank you.
I'm sure it will be useful to other distributors as well.

If you find yourself disturbed by debian users, don't hesitate to send them back
to us, as they should have in a first place : they have reportbug, bugs.debian.org,
and this mailing list.

Note that it was not /my/ opinions -- only FHS :
http://www.pathname.com/fhs/pub/fhs-2.3.html
though i recognize that i'm not so good at explaining it :)

Jérémy.