8:12 a.m.
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
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
8:33 a.m.
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
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
12:39 a.m.
Is that fixable somehow? There are already multiple bugs filled on this issue.
----- Original Message -----
From: "Tom Hughes" <tom(a)compton.nu>
To: "Node.js on Fedora" <nodejs(a)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
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
_______________________________________________
nodejs mailing list
nodejs(a)lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/nodejs@lists.fedoraproject.org
1:09 a.m.
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(a)compton.nu>
To: "Node.js on Fedora" <nodejs(a)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
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
6:41 a.m.
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(a)compton.nu>
> To: "Node.js on Fedora" <nodejs(a)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.
6:51 a.m.
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:
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.
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.
7:02 a.m.
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
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
7:09 a.m.
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.
2858
days inactive
2877
days old
nodejs@lists.fedoraproject.org
7 comments
3 participants
participants (3)
-
Stephen Gallagher -
Tom Hughes -
Zuzana Svetlikova