[arch-general] "npm" package issues
hi. [hope all are well, etc.] i use the npm package (for managing javascript packages). today i tried "pacman -Syu", and i got a number of errors about files under /usr/lib/node_modules/npm/node_modules that "exists in filesystem": ---- (182/182) checking for file conflicts error: failed to commit transaction (conflicting files) npm: /usr/lib/node_modules/npm/node_modules/meant/.github/workflows/ci.yml exists in filesystem npm: /usr/lib/node_modules/npm/node_modules/minimist/.travis.yml exists in filesystem ... (about minimist) ---- these are files that are not owned by the npm package. the relevant find command : find /usr/lib/node_modules/npm/node_modules/ -exec pacman -Qo {} \; | : grep -v 'is owned by npm 6.14.8-1' shows two files in some sort of ./.bin/ directory ---- error: No package owns /usr/lib/node_modules/npm/node_modules/.bin/node-gyp error: No package owns /usr/lib/node_modules/npm/node_modules/.bin/semver ---- and then a number in a small number of npm packages, namely in - meant (the .github subdirectory) - minimist (the whole directory, i think) - node-gyp (the whole directory) - semver (the whole directory) that are also in the "No package owns" state. note that [pacman -Syu] only complains about meant and minimist, not node-gyp or semver. first off, i wonder if anyone has ideas of how i ended up in this situation? i know that occasionally npm will exclaim, with enthusiasm, that a new, updated version, is available, and offer me a chance to update it. normally i don't run as root. but, if i had, in the past, sudo'd npm, and let it update itself, might *that* have produced this? then, second, i'm ignorant enough to not be sure what to do and am looking for advice. i can do [pacman --overwrite]. i could, i suppose (at what consequence?:) [pacman -R npm], then re-install. (though i assume i'd have the same problem, as pacman would presumably leave untouched the files not owned by npm.) i could just delete the offending files pacman complains about (meant/.github/..., and minimist/...). okay, thanks in advance for any thoughts. cheers, Greg
Hi Greg
first off, i wonder if anyone has ideas of how i ended up in this situation? i know that occasionally npm will exclaim, with enthusiasm, that a new, updated version, is available, and offer me a chance to update it. normally i don't run as root. but, if i had, in the past, sudo'd npm, and let it update itself, might *that* have produced this?
Did you install npm packages with the `-g` flag? from the manpage: ``` • global mode: npm installs packages into the install prefix at prefix/lib/node_modules and bins are installed in prefix/bin. ``` Regards -- Toni On 11/04 10:56, Greg Minshall via arch-general wrote:
hi. [hope all are well, etc.]
i use the npm package (for managing javascript packages).
today i tried "pacman -Syu", and i got a number of errors about files under /usr/lib/node_modules/npm/node_modules that "exists in filesystem": ---- (182/182) checking for file conflicts error: failed to commit transaction (conflicting files) npm: /usr/lib/node_modules/npm/node_modules/meant/.github/workflows/ci.yml exists in filesystem npm: /usr/lib/node_modules/npm/node_modules/minimist/.travis.yml exists in filesystem ... (about minimist) ----
these are files that are not owned by the npm package. the relevant find command
: find /usr/lib/node_modules/npm/node_modules/ -exec pacman -Qo {} \; | : grep -v 'is owned by npm 6.14.8-1'
shows two files in some sort of ./.bin/ directory ---- error: No package owns /usr/lib/node_modules/npm/node_modules/.bin/node-gyp error: No package owns /usr/lib/node_modules/npm/node_modules/.bin/semver ----
and then a number in a small number of npm packages, namely in - meant (the .github subdirectory) - minimist (the whole directory, i think) - node-gyp (the whole directory) - semver (the whole directory) that are also in the "No package owns" state.
note that [pacman -Syu] only complains about meant and minimist, not node-gyp or semver.
first off, i wonder if anyone has ideas of how i ended up in this situation? i know that occasionally npm will exclaim, with enthusiasm, that a new, updated version, is available, and offer me a chance to update it. normally i don't run as root. but, if i had, in the past, sudo'd npm, and let it update itself, might *that* have produced this?
then, second, i'm ignorant enough to not be sure what to do and am looking for advice. i can do [pacman --overwrite]. i could, i suppose (at what consequence?:) [pacman -R npm], then re-install. (though i assume i'd have the same problem, as pacman would presumably leave untouched the files not owned by npm.) i could just delete the offending files pacman complains about (meant/.github/..., and minimist/...).
okay, thanks in advance for any thoughts.
cheers, Greg
hi, Toni, thanks for the question. actually, i don't know, but if i bothered to sudo, it would have been to do -g (global). do you know (maybe it's a stupid, "well, duh!", question...) if, in that case, my system would become "un-pacman'able"? especially, in such as way as i've described. cheers, Greg
I think running `pacman -Syu --overwrite '/usr/lib/node_modules/*'` is safe. I have no idea how those files would end up there without using `sudo npm install -g` On Wed, Nov 4, 2020 at 11:56 AM Greg Minshall via arch-general <arch-general@archlinux.org> wrote:
hi. [hope all are well, etc.]
i use the npm package (for managing javascript packages).
today i tried "pacman -Syu", and i got a number of errors about files under /usr/lib/node_modules/npm/node_modules that "exists in filesystem": ---- (182/182) checking for file conflicts error: failed to commit transaction (conflicting files) npm: /usr/lib/node_modules/npm/node_modules/meant/.github/workflows/ci.yml exists in filesystem npm: /usr/lib/node_modules/npm/node_modules/minimist/.travis.yml exists in filesystem ... (about minimist) ----
these are files that are not owned by the npm package. the relevant find command
: find /usr/lib/node_modules/npm/node_modules/ -exec pacman -Qo {} \; | : grep -v 'is owned by npm 6.14.8-1'
shows two files in some sort of ./.bin/ directory ---- error: No package owns /usr/lib/node_modules/npm/node_modules/.bin/node-gyp error: No package owns /usr/lib/node_modules/npm/node_modules/.bin/semver ----
and then a number in a small number of npm packages, namely in - meant (the .github subdirectory) - minimist (the whole directory, i think) - node-gyp (the whole directory) - semver (the whole directory) that are also in the "No package owns" state.
note that [pacman -Syu] only complains about meant and minimist, not node-gyp or semver.
first off, i wonder if anyone has ideas of how i ended up in this situation? i know that occasionally npm will exclaim, with enthusiasm, that a new, updated version, is available, and offer me a chance to update it. normally i don't run as root. but, if i had, in the past, sudo'd npm, and let it update itself, might *that* have produced this?
then, second, i'm ignorant enough to not be sure what to do and am looking for advice. i can do [pacman --overwrite]. i could, i suppose (at what consequence?:) [pacman -R npm], then re-install. (though i assume i'd have the same problem, as pacman would presumably leave untouched the files not owned by npm.) i could just delete the offending files pacman complains about (meant/.github/..., and minimist/...).
okay, thanks in advance for any thoughts.
cheers, Greg
On Wed, 4 Nov 2020 at 15:17, Nick Shvelidze via arch-general < arch-general@archlinux.org> wrote:
I think running `pacman -Syu --overwrite '/usr/lib/node_modules/*'` is safe. I have no idea how those files would end up there without using `sudo npm install -g`
It would be good to also explicitly delete everything not owned by pacman in /usr/lib/node_modules. Otherwise you run the risk that some old (deleted upstream) files stick around and possibly cause weird issues. -- Maarten
thanks, Nick and Maarten. i guess all paths include some trepidation on my part. Nick -- i think it's a good assumption i *did* do some sort of "npm ... -g" action. i've often wondered how distributions (arch and others) deal with users of R, (now) npm, etc., doing a system-wide install of (sub-)packages. (and, in my right mind, i try to avoid doing such system-wide installs.) cheers, Greg
this is just a status update, mostly for anyone in the future who might find this useful for their problem. but, if anyone in the near-present has any comment, i'm happy. (and, i appreciate all the help up to now!) presumably this is all fallout from some historic "npm update -g". way too many details follow. i removed all files from /usr/lib/node_modules/npm/node_modules *not* owned by the npm package. then, [pacman -Syu] (without '--overwrite', as the offending files have been removed)succeeded. but, in the output, immediately after ---- (192/192) checking available disk space ---- (and some trailing ###...) there were a number of lines like ---- warning: could not get file information for usr/lib/node_modules/npm/node_modules/meant/.npmignore warning: could not get file information for usr/lib/node_modules/npm/node_modules/meant/.travis.yml warning: could not get file information for usr/lib/node_modules/npm/node_modules/rc/node_modules/ warning: could not get file information for usr/lib/node_modules/npm/node_modules/rc/node_modules/minimist/ warning: could not get file information for usr/lib/node_modules/npm/node_modules/rc/node_modules/minimist/.travis.yml warning: could not get file information for usr/lib/node_modules/npm/node_modules/rc/node_modules/minimist/LICENSE warning: could not get file information for usr/lib/node_modules/npm/node_modules/rc/node_modules/minimist/example/ ---- [pacman -Qo] says they are all owned by no package. if that is so, what is causing the upgrade process to look for them? then, after those warnings (in case context is of use) ---- :: Running pre-transaction hooks... (1/2) Removing linux initcpios... (2/2) Unregistering Haskell modules... :: Processing package changes... ( 1/192) upgrading alsa-card-profiles ( 2/192) upgrading alsa-firmware ---- (with some trailing ###... on the last two lines). and, after a bit ---- (144/192) upgrading npm (145/192) upgrading npm-check-updates ---- (ditto) .../rc/package.json shows a dependency on minimist. [pacman -Qo] doesn't seem to know any of the warned-about files; and [pacman -Qkk npm] says "0 altered files" (ditto for [pacman -Qkk npm-check-updates]). (and, everything under /usr/lib/node_modules/npm/node_modules is owned by (the new) "npm 6.14.8-2". unfortunately, i did *not* run [pacman -Qkk npm] *before* doing [pacman -Syu]. cheers, again thanks, sorry for all the detail, Greg
On 11/4/20 12:03 PM, Greg Minshall via arch-general wrote:
(145/192) upgrading npm-check-updates ---- Did you explicitly install npm-check-updates or was it a dependency of something else?
.../rc/package.json shows a dependency on minimist. Looks like npm-check-updates depends on something else called rc-load-config, which doesn't depend on anything called "rc", which makes me think that "rc" is built into npm or nodejs. I'm not a NodeJS expert, though, so don't take my word for it.
-- Yash Karandikar
Yash, i (according to the pacman log) explicitly installed npm-check-updates. (i've just now removed it; i think i installed it when i was initially flailing around, trying to understand the npm-verse.) in terms of arch packages, the arch package page ---- https://www.archlinux.org/packages/community/any/npm-check-updates/ says the arch package npm-check-updates depends on the arch npm and semver packages. in addition, npm-check-updates depends on a large number of *npm* packages, including the one you mention, rc-config-loader. in addition, the arch *npm* package includes (the npm package) "rc". it's a convoluted it world out there. cheers, Greg ps -- that every web site i build has its own local copies of all the npm packages used for that site is both a (simplification) boon and a (disk usage) shame. but, i digress.
On 11/4/20 1:03 PM, Greg Minshall via arch-general wrote:
this is just a status update, mostly for anyone in the future who might find this useful for their problem. but, if anyone in the near-present has any comment, i'm happy. (and, i appreciate all the help up to now!)
presumably this is all fallout from some historic "npm update -g".
way too many details follow.
i removed all files from /usr/lib/node_modules/npm/node_modules *not* owned by the npm package.
then, [pacman -Syu] (without '--overwrite', as the offending files have been removed)succeeded.
but, in the output, immediately after ---- (192/192) checking available disk space ---- (and some trailing ###...)
there were a number of lines like ---- warning: could not get file information for usr/lib/node_modules/npm/node_modules/meant/.npmignore warning: could not get file information for usr/lib/node_modules/npm/node_modules/meant/.travis.yml warning: could not get file information for usr/lib/node_modules/npm/node_modules/rc/node_modules/ warning: could not get file information for usr/lib/node_modules/npm/node_modules/rc/node_modules/minimist/ warning: could not get file information for usr/lib/node_modules/npm/node_modules/rc/node_modules/minimist/.travis.yml warning: could not get file information for usr/lib/node_modules/npm/node_modules/rc/node_modules/minimist/LICENSE warning: could not get file information for usr/lib/node_modules/npm/node_modules/rc/node_modules/minimist/example/ ---- [pacman -Qo] says they are all owned by no package. if that is so, what is causing the upgrade process to look for them?
This pacman warning indicates that while deleting the files from the old copy of the package, it could not find some files to delete, before installing the new copy of the package. The files should definitely be owned, though... I suspect your issue is due to upgrading the pacman version, resulting in some files that could not be deleted due to not existing, but were not part of the new package and therefore did not exist afterward either. -- Eli Schwartz Bug Wrangler and Trusted User
Eli,
The files should definitely be owned, though... I suspect your issue is due to upgrading the pacman version, resulting in some files that could not be deleted due to not existing, but were not part of the new package and therefore did not exist afterward either.
thanks. in theory (modulo fat fingers), the only files i *removed* were ones that [pacman -Qo] said were unowned. and, *those* files were unowned post [pacman -Syu]. a time machine would help. absent that, again, i guess we'll "let that mystery be". thanks again. cheers, Greg
participants (6)
-
Eli Schwartz
-
eye＠eyenx.ch
-
Greg Minshall
-
Maarten de Vries
-
Nick Shvelidze
-
Yash Karandikar