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...
5 years, 4 months
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, 7 months
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, 7 months
Re: NodeJS in EPEL for AltArches
by Stephen Gallagher
On 08/28/2016 04:28 AM, Peter Robinson wrote:
> Hi Stephen,
>
> Before I forget again!
>
> When you do the new nodejs in EPEL can we add aarch64 and %{power64}
> to the supported arches macro. The Power64 is already done, we'll be
> doing aarch64 before the end of Sept. It'll save on the churn of
> rebuilding everything just to get a new macro.
>
> Sadly it does mean that all packages, even noarch, that have the macro
> do need to be rebuild but I suspect you'll be rebasing a lot to the
> new Fedora ones as part of the process so as long as the core macro is
> appropriately updated first it'll all be good.
>
> Peter
>
CCing the Node.js list.
Yeah, looks like we will need to do that mass-rebuild for the EPEL update after
all, so once we figure out how to deal with the OpenSSL situation, I'll ask you
to create a side-tag for us to work from, Peter.
Unfortunately, even the Red Hat Enterprise Linux 7.3 beta apparently includes
OpenSSL 1.0.1e so we need to figure out a new approach.
7 years, 7 months
Updating EPEL
by Zuzana Svetlikova
Hi,
since nodejs currently present in EPEL is archaic and going EOL in ~7w,
it might be time to finally update it.
If anyone has any comments or suggestions, I'm all ears.
Otherwise I'll start with the update tomorrow or on Friday.
Regards
Zuzka
7 years, 8 months
