It seems that the standalone npm package hasn't been retired, which creates a bit of a problem...
As things stand in F24 we have npm providing 0:3.5.4-5 and also nodejs providing npm 1:2.15.5 and obsoleting npm < 0:3.5.4-6.
I'm not sure what happens if you update with dnf system-upgrade but if you have both nodejs and npm installed and try and distro-sync to F24 then you will fail with:
Error: package nodejs-1:4.4.5-1.fc24.x86_64 obsoletes npm < 3.5.4-6 provided by npm-3.5.4-5.fc24.noarch
Because it tries to update both packages but the updated npm conflicts with the obsolete in nodejs.
The workaround is to remove npm before upgrading, but we should retire npm I think at least in rawhide - not sure if we can still do that in F24 or if it is too late?
We should probably also find out what happens when using the official upgrade method...
Tom
On 10/06/16 14:12, Tom Hughes wrote:
I'm not sure what happens if you update with dnf system-upgrade but if you have both nodejs and npm installed and try and distro-sync to F24 then you will fail with:
I've tried system-upgrade and it fails in the same way.
The good news is that --allowerasing, which is suggested by system-upgrade when it fails, works with both distro-sync and system-upgrade and appears to do the right thing in allowing nodejs to replace npm.
Tom
Is that fixable somehow? There are already multiple bugs filled on this issue.
----- Original Message ----- From: "Tom Hughes" tom@compton.nu To: "Node.js on Fedora" nodejs@lists.fedoraproject.org Sent: Friday, June 10, 2016 3:33:15 PM Subject: Re: F24 and npm
On 10/06/16 14:12, Tom Hughes wrote:
I'm not sure what happens if you update with dnf system-upgrade but if you have both nodejs and npm installed and try and distro-sync to F24 then you will fail with:
I've tried system-upgrade and it fails in the same way.
The good news is that --allowerasing, which is suggested by system-upgrade when it fails, works with both distro-sync and system-upgrade and appears to do the right thing in allowing nodejs to replace npm.
Tom
On 29/06/16 06:39, Zuzana Svetlikova wrote:
Is that fixable somehow? There are already multiple bugs filled on this issue.
Only by retiring npm in F24 I think, which I don't believe is possible now it has been released.
Of course if anybody at all had replied when I raised this then me might have been able to do something...
For now I suggest adding it to the "common bugs" page.
Tom
----- Original Message ----- From: "Tom Hughes" tom@compton.nu To: "Node.js on Fedora" nodejs@lists.fedoraproject.org Sent: Friday, June 10, 2016 3:33:15 PM Subject: Re: F24 and npm
On 10/06/16 14:12, Tom Hughes wrote:
I'm not sure what happens if you update with dnf system-upgrade but if you have both nodejs and npm installed and try and distro-sync to F24 then you will fail with:
I've tried system-upgrade and it fails in the same way.
The good news is that --allowerasing, which is suggested by system-upgrade when it fails, works with both distro-sync and system-upgrade and appears to do the right thing in allowing nodejs to replace npm.
Tom
On 06/29/2016 02:09 AM, Tom Hughes wrote:
On 29/06/16 06:39, Zuzana Svetlikova wrote:
Is that fixable somehow? There are already multiple bugs filled on this issue.
Only by retiring npm in F24 I think, which I don't believe is possible now it has been released.
Of course if anybody at all had replied when I raised this then me might have been able to do something...
For now I suggest adding it to the "common bugs" page.
Tom
----- Original Message ----- From: "Tom Hughes" tom@compton.nu To: "Node.js on Fedora" nodejs@lists.fedoraproject.org Sent: Friday, June 10, 2016 3:33:15 PM Subject: Re: F24 and npm
On 10/06/16 14:12, Tom Hughes wrote:
I'm not sure what happens if you update with dnf system-upgrade but if you have both nodejs and npm installed and try and distro-sync to F24 then you will fail with:
I've tried system-upgrade and it fails in the same way.
The good news is that --allowerasing, which is suggested by system-upgrade when it fails, works with both distro-sync and system-upgrade and appears to do the right thing in allowing nodejs to replace npm.
Tom
Sorry, Tom. I didn't see this until right now. It's strange, because I *did* go through the process of retiring in F24, I thought.
I suspect the problem may actually be the virtual 'Provides: npm(npm)' since we had to drop the epoch on that for other reasons. Since that virtual Provides went backwards and other packages in the transaction have explicit "Requires: npm(npm) >= something" in them, DNF is trying to pull in the package that satisfies the highest version of that virtual dependency available.
So you're right, we should have retired it (and I *swear* that I did, but it never happened). At this point, we have three choices:
1) Hope that the NPM bundled in Node.js eventually updates past 3.5.4 (unlikely). 2) Figure out how to fix the automatic dependency generation so that it's aware and tolerant of epochs. 3) Drop the bundled NPM from Node.js in F24 only, create an updated NPM package (bundled, to avoid the dependency nightmare) providing the version we're going to have in Fedora 25 (and tracking it).
I think 3) is the best choice. People will get newer NPM features (and NPM is backwards-compatible), and it still lets us kill off the separate NPM package in F25.
On 06/29/2016 07:41 AM, Stephen Gallagher wrote:
I suspect the problem may actually be the virtual 'Provides: npm(npm)' since we had to drop the epoch on that for other reasons. Since that virtual Provides went backwards and other packages in the transaction have explicit "Requires: npm(npm) >= something" in them, DNF is trying to pull in the package that satisfies the highest version of that virtual dependency available.
So you're right, we should have retired it (and I *swear* that I did, but it never happened). At this point, we have three choices:
- Hope that the NPM bundled in Node.js eventually updates past 3.5.4 (unlikely).
- Figure out how to fix the automatic dependency generation so that it's aware
and tolerant of epochs. 3) Drop the bundled NPM from Node.js in F24 only, create an updated NPM package (bundled, to avoid the dependency nightmare) providing the version we're going to have in Fedora 25 (and tracking it).
I think 3) is the best choice. People will get newer NPM features (and NPM is backwards-compatible), and it still lets us kill off the separate NPM package in F25.
I forgot to clarify 3) a little.
When F25 rolls around, it will get dropped on upgrade. We will just have to make sure that the release field on F25 is always at least one higher than on F24 so we can bump the Obsoletes safely. Probably the path of least effort would be to bump the epoch on the npm virtual Provides in F25 so that we don't have to issue an update every time F24 updates.
So F24's npm package would be e.g. npm-3.9.5-1.fc24: Version: 3.9.5 Release: 1%{?dist} Epoch: 1
F25's nodejs package would have to have: %global npm_epoch 2 Provides: npm = 2:%{npm_version}-%{release} Provides: npm(npm) = %{npm_version}-%{release} Obsoletes: npm < 2:3.9.5
This would avoid the problem with the virtual Provides being higher than the older version because even the non-epoched one is still higher than anything previously released in F24 or F23.
On 29/06/16 12:41, Stephen Gallagher wrote:
I suspect the problem may actually be the virtual 'Provides: npm(npm)' since we had to drop the epoch on that for other reasons. Since that virtual Provides went backwards and other packages in the transaction have explicit "Requires: npm(npm) >= something" in them, DNF is trying to pull in the package that satisfies the highest version of that virtual dependency available.
There is only one package in the repo that requires npm(npm) though and that is kosmtik which currently requires:
npm(npm) >= 2.15.5 npm(npm) < 3
Which matches the nodejs provided version. Note that it was broken and requiring v3 but I fixed that in a zero day update.
Even without kosmtik installed you still hit the problem on upgrade though so long as you have both npm and nodejs installed.
Tom
On 06/29/2016 08:02 AM, Tom Hughes wrote:
On 29/06/16 12:41, Stephen Gallagher wrote:
I suspect the problem may actually be the virtual 'Provides: npm(npm)' since we had to drop the epoch on that for other reasons. Since that virtual Provides went backwards and other packages in the transaction have explicit "Requires: npm(npm) >= something" in them, DNF is trying to pull in the package that satisfies the highest version of that virtual dependency available.
There is only one package in the repo that requires npm(npm) though and that is kosmtik which currently requires:
npm(npm) >= 2.15.5 npm(npm) < 3
Which matches the nodejs provided version. Note that it was broken and requiring v3 but I fixed that in a zero day update.
Even without kosmtik installed you still hit the problem on upgrade though so long as you have both npm and nodejs installed.
Tom
I suppose we need to run some experiments, but I suspect that DNF is seeing "Hey, I have a package that Provides: npm(npm) = 2.15.5 and one that Provides: npm = 3.5.4. I should pull that one in."
It's debatable whether this is a bug in DNF or us, because downgrades have always been a pain in the neck.
nodejs@lists.fedoraproject.org
-
Stephen Gallagher -
Tom Hughes -
Zuzana Svetlikova