[Pkg-javascript-devel] npm debian package

[Isaac Schlueter]

Ok, pushed to master.  It'll be in 1.0.95.  Let's see how it goes :)

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