Source0 for nodejs modules
by Piotr Popieluch
The the Node.js guidelines say about Source0 [1]:
"The canonical method for shipping most node modules is tarballs from
the npm registry"
and
"This method [PP: tarbals from npm] should be preferred to using
checkouts from git or automatically generated tarballs from GitHub."
But I think that in following cases it would be better to use sources
from the upstream project:
1) When the license is not included in NPM but is in upstream project.
o Because we are not supposed to ship the license separate from the
sources.
2) When the tests are not included.
o In this case we need to download the sources from NPM and from
upstream project, which seems redundant and a waste of work.
3) When NPM content is generated and source files are not in NPM.
o This would mean to download sources from NPM and upstream project,
delete the NPM sources in prep and generate the files again.
Are there good reason to enforce the use of NPM sources which I am
missing? What is your opinion?
I would like to suggest to ad those three exceptions to the guidelines.
Piotr
[1]:
https://fedoraproject.org/wiki/Packaging:Node.js?rd=Node.js/Packagers#Usi...
4 years, 9 months
EPEL 7 Node.js Uplift
by Stephen Gallagher
I updated the Bodhi update in EPEL to the latest 6.7.0 security release last
night. I just want to remind people that there remain only three days until EOL
of 0.10.x, so I think we really need to make the cut-over today or tomorrow by
providing karma to push the update to stable. It takes at least a day to make it
to most mirrors.
I wish we had a bit more time for this, but security updates seem to be coming
at an accelerated pace lately. I missed Jim Perrin's original note about a
Fedora Magazine post for EPEL and CentOS to link to (sorry about that, Jim), but
I'll see if I can get something written up and published today. It's probably
"too little, too late", but I'll at least provide the justification.
Part of the reason I support making the cutover immediately is because the
high-severity security updates from last night *also* impact 0.10.x and we don't
have a meaningful way to deliver 0.10.47 to EPEL 7 right now (since the 6.7.0
package is in epel-testing). We either need to cut over to 6.7.0 or else
withdraw that update, push the 0.10.47 update, wait for it to go stable and then
reintroduce 6.7.0. This seems like a large amount of effort for very little benefit.
(Apologies for stream-of-consciousness; I'm thinking this through as I type)
I do see one alternative if we want to provide a little more time in testing for
6.x... we could do the above 0.10.47 release by pulling 6.x, *rush* that in by
karma-cheating[*], put 6.7.0 back in updates testing and hold off on the cutover
for X days or the next security release, whichever comes first.
That's fairly convoluted and I'm not personally willing to do the work for it,
but if someone wants to take over I'm game.
[*] Setting karma requirements to 1 and having one of us hand-wave it.
6 years, 12 months
Newbie question . . fetch_kindle.js
by Philip Rhoades
People,
This looks like a very low volume list so I guess if there is no response I should try the main Fedora user list . .
Anyway, I am trying to get this working:
https://gist.github.com/yangchenyun/a1c123935d82f5e25d57
on F25 x86_64
and I am getting a sqlite3 error so I did:
dnf install nodejs-sqlite3
with no improvement - I did try:
npm install sqlite3 --build-from-source
but got a whole lot of errors and in any case, I would like to stick to just RPMs if I can . .
Suggestions?
Thanks,
Phil.
7 years
NodeJS on Fedora Rawhide
by Robert Van Voorhees
Hey guys, anyone notice that updating to Node 6.5 is pulling in a whole lot
more stuff now than it used to? I'm trying to make the move from 6.3 to
6.5, and it's forcing updates to gnome-shell, uninstalling Firefox, and a
whole range of weird behavior. Does it have something to do with upgrading
v8, or one of the other dependencies?
7 years
Strategy for Node.js upgrade in EPEL 7
by Stephen Gallagher
Yesterday, I built the latest upstream version of Node.js for EPEL 7 (this
version will be supported until 2019-04-01)
I have added it to the buildroot overrides so that anyone can rebuild their npm
modules at will. This *is* an API/ABI-breaking upgrade, so some modules will
fail to function on this version. We don't know ahead of time which ones will do
so, except for binary modules.
I am electing *not* to build in a side-tag for this. Many of the noarch packages
will just work (or they won't, and a rebuild wouldn't help us detect this). I am
therefore putting out a request to anyone using nodejs-* packages in EPEL to
please install nodejs from epel-testing[2] and help us find any issues before
October.
If you maintain a nodejs-* package in EPEL, please test that it continues to
work with Node.js 6.x. If it does not, please update it and build it in Koji. If
the update is compatible with 0.10.x, feel free to submit it to Bodhi; if it is
not (or you simply want to push them all together), please notify me directly I
will add it to the Bodhi update for nodejs so that it goes stable at the same
time as the interpreter.
Due to upstream terminating support for 0.10.x on 2016-10-01, we *will* be
cutting over to 6.x on or around that date, so this testing request is
time-sensitive.
[1] There's a long story behind this, but the short version is that the bundling
style of npm makes it basically impossible to maintain, as even bugfix releases
result in a huge tangled mess of dependencies. It is infeasible to keep up with
bugfix and security updates. Node.js upstream is highly responsible and
responsive about security issues, so we considered it an acceptable risk to
bundle npm with the main package.
[2] https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-epel/ also has
it, if your epel-testing mirrors don't have it yet.
7 years
Re: nodejs update
by Stephen Gallagher
On 08/11/2016 07:43 AM, Stephen Gallagher wrote:
> On 08/11/2016 05:16 AM, Zuzana Svetlikova wrote:
>> Hi!
>>
>> As some of you may know, nodejs package that is present in
>> EPEL is pretty outdated. The current v0.10 that we have will
>> go EOL in October and npm (package manager) is already not
>> maintained.
>>
>> Currently, upstreams' plan is to have two versions of Long
>> Term Support (LTS) at once, one in active development and one
>> in maintenance mode.
>> Currently active is v4, which is switching to maintenance in
>> April and v6 which is switching to LTS in October.
>> This is also reason why we would like to skip v4, although
>> both will get security updates. Nodejs v6 also comes with
>> newer npm and v8 (which might best be bundled, as it is in
>> Fedora and Software Collections) (v8 might concern ruby and
>> database maintainers, but old v8 package still remains in
>> the repo).
>>
>> There was also an idea to have both LTS versions in repo,
>> but we're not quite sure, how we'd do it and if it's even a
>> good idea.
>>
>> Also, another thing is, if it is worth of updating every year
>> to new LTS or update only after the current one goes EOL.
>> According to guidelines, I'd say it's the latter, but it's
>> not exactly how node development works and some feedback from
>> users on this would be nice, because I have none.
>>
>>
>> tl;dr Need to update nodejs, but can't decide if v4 or v6,
>> v4: will update sooner, shorter support (2018-04-01)
>> v6: longer support (2019-04-01), *might* break more things,
>> won't be in stable sooner than mid-October if everything
>> goes well
>
> FYI, I think this tl;dr missed explaining why v6 won't be in stable until
> mid-October. What Zuzana and I discussed on another list is that the Node.js v6
> schedule has it going into LTS mode on the same day that 0.10.x reaches EOL.
> However, v6 is already out and available. The major thing that changes at that
> point is just that from then on, they commit to adding no more major features
> (as I understand it). This is the best moment for us to switch over to it.
>
> However, in the meantime we will probably want to be carrying 6.x in
> updates-testing for at least a month prior to declaring it stable (with
> autokarma disabled) with wide announcements about the impending upgrade. This
> will be safe to do since Node.js 6.x has already reached a point where no
> backwards-incompatible changes are allowed in, so we can start the migration
> process early.
>
OK, as we stated before, we really need to get Node.js 6.x into the
updates-testing repository soon. We mentioned that we wanted it to sit there for
at least a month before we cut over, and "at least a month" means "by next week"
since the cut over is planned for 2016-10-01.
I'm putting together a COPR right now as a first pass at this upgrade:
https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-epel/
I've run into the following blocker issues:
* We cannot jump to 6.x in EPEL 6 easily at this time, because upstream strictly
requires GCC 4.8 or later and we only have 4.4 in EPEL 6. It might be possible
to resolve this with SCLs, but I am no expert there. Zuzana?
* Node.js 4.x and 6.x both *strictly* require functionality from OpenSSL 1.0.2
and cannot run (or indeed build) against OpenSSL 1.0.1. Currently, both EPEL 6
and EPEL 7 have 1.0.1 in their buildroots. I am not aware of any solution (SCL
or otherwise) for linking EPEL to a newer version of OpenSSL.
The OpenSSL 1.0.2 problem is a significant one; we cannot build against the
bundled copy of OpenSSL because it includes patented algorithms that are not
acceptable for inclusion in Fedora. We also cannot trivially backport Fedora's
OpenSSL 1.0.2 packages because EPEL forbids upgrading packages provided by the
base RHEL/CentOS repositories.
Right now, the only thing I can think of would be for someone to build a
parallel-installable OpenSSL 1.0.2 package for EPEL 6 and EPEL 7 (similar to the
openssl101e package available for EPEL 5) and patch our specfile to be able to
work with that instead.
This is a task I'm not anxious to embark upon personally; there is too much
overhead in maintaining a fork of OpenSSL to make me comfortable.
How shall we proceed?
7 years
Node 6.5.0
by Tom Hughes
The nodejs 6.5.0 build that is running now breaks v8 abi so binary
extensions will need to be rebuilt.
I've got my script ready to go and will run it for rawhide and f25 once
the f25 build of nodejs completes - ideally we will then need to add
those to the same bodhi update as nodejs for f25.
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
7 years
