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.