Bug 2177117 - rpm macros %nodejs_sitearch and %nodejs_sitelib point to symlink /usr/lib/node_modules
Summary: rpm macros %nodejs_sitearch and %nodejs_sitelib point to symlink /usr/lib/nod...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: nodejs-packaging
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: NodeJS Packaging SIG
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-03-10 04:08 UTC by Mattias Ellert
Modified: 2023-03-19 01:46 UTC (History)
6 users (show)

Fixed In Version: nodejs-packaging-2023.03-1.fc38 nodejs-packaging-2023.03-1.fc37
Doc Type: ---
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-03-15 00:17:28 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Mattias Ellert 2023-03-10 04:08:11 UTC
Description of problem:

When the nodejs major version is changed, ownership of files installed in %nodejs_sitearch and %nodejs_sitelib is lost and rpm can not keep track of them.

1. nodejs version is X, /usr/lib/node_modules is symlink to /usr/lib/node_modules_x
2. Package pkg installs module in /usr/lib/node_modules/pkg that end up in
   /usr/lib/node_modules_X/pkg due to the symlink
3. nodejs is updated to version X+1, /usr/lib/node_modules in now symlink to
   /usr/lib/node_modules_X+1
4. Package pkg installed in point 2 should according to rpm now still own files in
   /usr/lib/node_modules/pkg, however since a symlink in this path changed due to
   the update in point 3 the files no longer exist in the location registered in rpm.
   The package is no longer functional and rpm reports missing files for the package.
   The files that were installed are now zombies lost by the package management
   system and will never be cleaned up.

Version-Release number of selected component (if applicable):

nodejs-packaging-2021.06-6.fc37
nodejs-packaging-2022.10-2.fc38

How reproducible:
Always

Steps to Reproduce:
1. See above

Actual results:
Zombie files not tracked by rpm.
Broken packages with missing files.

Expected results:
Files properly tracked by rpm.
No broken packages with missing files.

Additional info:

Possible fix:
The %nodejs_sitearch and %nodejs_sitelib macros should be updated to contain the versioned directory name. This is similar to %python3_sitearch and %python3_sitelib.

After a recent update of nodejs I have broken packages:

$ LANG=C rpm -V uglify-js
missing     /usr/lib/node_modules/uglify-js
missing     /usr/lib/node_modules/uglify-js@3
missing     /usr/lib/node_modules/uglify-js@3/bin
missing     /usr/lib/node_modules/uglify-js@3/bin/uglifyjs
missing     /usr/lib/node_modules/uglify-js@3/lib
missing     /usr/lib/node_modules/uglify-js@3/package.json
missing     /usr/lib/node_modules/uglify-js@3/tools
missing     /usr/lib/node_modules/uglify-js@3/tools/domprops.html
missing     /usr/lib/node_modules/uglify-js@3/tools/domprops.json
missing     /usr/lib/node_modules/uglify-js@3/tools/exports.js
missing     /usr/lib/node_modules/uglify-js@3/tools/node.js
missing     /usr/lib/node_modules/uglify-js@3/tools/tty.js

The scenario here was slightly different from the one described above since this was not an update that changed the symlink to a new target, but the update that introduced the symlink replacing the existing directory with a symlink in its pretrans scriptlet:

$ rpm -q nodejs --scripts
pretrans scriptlet (using <lua>):
path = "/usr/lib/node_modules"
st = posix.stat(path)
if st and st.type == "directory" then
  status = os.rename(path, path .. ".rpmmoved")
  if not status then
    suffix = 0
    while not status do
      suffix = suffix + 1
      status = os.rename(path .. ".rpmmoved", path .. ".rpmmoved." .. suffix)
    end
    os.rename(path, path .. ".rpmmoved")
  end
end

The main cause is the same though: the nodejs package does things during installation/upgrade that breaks other packages.

With the current values for the rpm macros this breakage will repeat itself every nodejs major version update.

Comment 1 Fedora Update System 2023-03-10 16:04:15 UTC
FEDORA-2023-2108ef109d has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-2108ef109d

Comment 2 Fedora Update System 2023-03-11 05:24:29 UTC
FEDORA-2023-be0ac3846f has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-be0ac3846f`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-be0ac3846f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 3 Fedora Update System 2023-03-11 05:39:20 UTC
FEDORA-2023-2108ef109d has been pushed to the Fedora 38 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-2108ef109d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 4 Fedora Update System 2023-03-15 00:17:28 UTC
FEDORA-2023-2108ef109d has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 5 Fedora Update System 2023-03-19 01:46:54 UTC
FEDORA-2023-be0ac3846f has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.