Do not use NPM 5.7

Post by wejick » Thu, Feb 22, 2018, 4:53 PM UTC

jguimont wrote: post #33

jlgaddis wrote: post #25

I just can't feel sorry for folks when I see comments like this one: > This destroyed 3 production server after a single deploy! I do think that the developers have a duty to do some testing of their software before putting out releases/updates. However, users also have a duty to perform sufficient testing before they push new versions to their production environments. In my opinion, it's kinda like losing data becau…

I am the one who reported this ;) In fact that was a single production server that I tried to reinstall 3 times before catching it was not really one of the commits that was doing this. No data was lost or connectivity (as long as you do not reboot it), you just lose any ssh connection/login. Should I have done this on a staging server? Sure, but that does not change the fact that I would have had to rebuild the whol…

Post by Piskvorrr » Thu, Feb 22, 2018, 4:55 PM UTC

vetinari wrote: post #53

y4mi wrote: post #30

Earlier quoted context omitted.

You probably meant rpm and dpkg... Or you'd have to compare yum, zypper, apt, pacman and whatever else is out there. But, I'm certain the parent didn't mean that. Dpkg and rpm both allow packages to overwrite files from each other and, more dangerously, allow fully authorized post-install scripts. And they're often necessary for sane package management (create user, initiate database), but could be exploited to wreck…

Yes, I meant dpkg. Not sure about dpkg, but rpm does not allow two packages to own the same file. If you try to install package, that contains file owned by another, already installed package, the installation will fail (you can try that with installing an amd64 package that owns something in /usr/share, and then try to install the i386 version). Yes, post-install scripts are dangerous and rpm folks are doing small s…

Post by [deleted] » Thu, Feb 22, 2018, 4:57 PM UTC

foepys wrote: post #24

Apart from being a horrific bug, why are people running npm as root? Why don't they install it somewhere below $HOME and modify $PATH? npm is working fine without root permissions. Everything is super dangerous as root, one should avoid using root at all costs until there is no other way.

Post by Silhouette » Thu, Feb 22, 2018, 4:59 PM UTC

vetinari wrote: post #56

Silhouette wrote: post #41

Earlier quoted context omitted.

You mean something, that won't allow two packages to own the same file? Something, like, rpm or apt? No, not really. For one thing, package managers are only useful on packages supplied by the distro (or otherwise bundled using that convention), and we need something that allows for installing (and uninstalling, and backing up configurations for, and...) software safely and systematically in the general case. For ano…

> For one thing, package managers are only useful on packages supplied by the distro (or otherwise bundled using that convention), and we need something that allows for installing (and uninstalling, and backing up configurations for, and...) software safely and systematically in the general case. There's nothing that limits rpm/deb to distribution. Anyone who publishes a tarball with software, can publish rpm/deb as…

Post by Shank » Thu, Feb 22, 2018, 5:00 PM UTC

diggan wrote: post #51

reificator wrote: post #20

Earlier quoted context omitted.

I completely agree with you. But in fairness, I can't count the number of times that I've needed to fix things after people treated `sudo npm` as Simon Says[1]. I'm sure they struggled a lot with that issue before coming to this solution. Was it the right solution? Absolutely not. But that's not the point I'm trying to make. It's all too easy to tunnel vision on a particular solution. I've done it plenty of times, an…

I don't remember exactly what tool does this, but one package manager (can be homebrew but long time ago I used homebrew) warns users if you are running it as root, since it should install packages as the user. I think npm could implement a similar strategy and educate the users how packages should really be installed.