Bug 1974709 - nodejs-packaging-bundler copies tarballs to hard-coded directory
Summary: nodejs-packaging-bundler copies tarballs to hard-coded directory
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: nodejs-packaging
Version: 34
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: 2021-06-22 11:04 UTC by Dominik 'Rathann' Mierzejewski
Modified: 2021-07-02 01:20 UTC (History)
8 users (show)

Fixed In Version: nodejs-packaging-2021.06-2.fc34 nodejs-packaging-2021.06-2.fc33
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-07-01 01:14:07 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Dominik 'Rathann' Mierzejewski 2021-06-22 11:04:58 UTC
Description of problem:
The destination for downloaded npm bundles is hard-coded in the nodejs-packaging-bundler script.

Version-Release number of selected component (if applicable):
nodejs-packaging-bundler-2021.06-1.fc34.noarch

How reproducible:
Always

Steps to Reproduce:
1. In ~/.rpmmacros, set %_sourcedir to a non-default location, e.g. %{_topdir}/SOURCES/%{name}
2. Run nodejs-packaging-bundler web-ext

Actual results:
...
'web-ext-6.2.0-bundled-licenses.txt' -> '/home/rathann/rpmbuild/SOURCES/web-ext-6.2.0-bundled-licenses.txt'
'web-ext-6.2.0-nm-dev.tgz' -> '/home/rathann/rpmbuild/SOURCES/web-ext-6.2.0-nm-dev.tgz'
'web-ext-6.2.0-nm-prod.tgz' -> '/home/rathann/rpmbuild/SOURCES/web-ext-6.2.0-nm-prod.tgz'
'web-ext-6.2.0.tgz' -> '/home/rathann/rpmbuild/SOURCES/web-ext-6.2.0.tgz'

Expected results:
The files should end up in %_sourcedir, i.e. /home/rathann/build/SOURCES/nodejs-web-ext/*

Comment 1 Ben Beasley 2021-06-22 12:11:06 UTC
It’s easy to fix this:

https://src.fedoraproject.org/fork/music/rpms/nodejs-packaging/c/5385bed9507ac1e019c71170ee396506c62e74e0
https://src.fedoraproject.org/fork/music/rpms/nodejs-packaging/c/fb332bd0eafdd5bc8aad8d93e4e3f62366f089a8

However, I don’t see any way the script can be informed of the intended RPM package name, so in your example, %{name} would not be expanded.

It’s possible to evaluate %{_srcdir} with %{name} set to the NPM package name provided as a command-line argument, which would often be the same as the intended RPM name for NodeJS packages under the current guidelines, but not reliably so. Thoughts on whether this would be helpful or wise are welcome.

If you’re satisfied, I’ll submit the linked changes as a PR.

Comment 2 Dominik 'Rathann' Mierzejewski 2021-06-22 12:49:57 UTC
Thanks for the quick response! You're right, evaluating %{name} needs spec file parsing or explicit definition. I think the intended (source) package name is "nodejs-${PACKAGE}", so that could be used as the default if not specified.

Either way, the two commits do fix the general issue, so they are good to merge in my opinion.

Comment 3 Ben Beasley 2021-06-22 14:59:09 UTC
> Thanks for the quick response!

You’re welcome! I’m just an interested community member who’s looked inside this script before…

> I think the intended (source) package name is "nodejs-${PACKAGE}", so that could be used as the default if not specified.

This is true for library packages under https://docs.fedoraproject.org/en-US/packaging-guidelines/Node.js/#_naming_guidelines, but we are mostly not packaging those anymore (https://docs.fedoraproject.org/en-US/packaging-guidelines/Node.js/#_what_to_package).

Most of what is left is application packages that provide command-line tools, which fall under the general-purpose package naming guidelines and shouldn’t generally have the “nodejs-” prefix. I suspect failing to interpolate %{name} is probably better than guessing unreliably.

I’ve submitted these changes as a PR: https://src.fedoraproject.org/rpms/nodejs-packaging/pull-request/6

Comment 4 Fedora Update System 2021-06-22 18:24:47 UTC
FEDORA-2021-38f0e2641d has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-38f0e2641d

Comment 5 Fedora Update System 2021-06-22 18:24:48 UTC
FEDORA-2021-367bbf266e has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-367bbf266e

Comment 6 Fedora Update System 2021-06-23 02:04:41 UTC
FEDORA-2021-38f0e2641d has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-38f0e2641d`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-38f0e2641d

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

Comment 7 Fedora Update System 2021-06-24 14:46:47 UTC
FEDORA-2021-367bbf266e has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-367bbf266e`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-367bbf266e

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

Comment 8 Fedora Update System 2021-07-01 01:14:07 UTC
FEDORA-2021-38f0e2641d has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 9 Fedora Update System 2021-07-02 01:20:34 UTC
FEDORA-2021-367bbf266e has been pushed to the Fedora 33 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.