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
Node.js security update
by Zuzana Svetlikova
Hi,
there's node.js security update coming tomorrow
and since Stephen no longer has time for the package,
I would like to take care of it.
If anyone has any intention to update the package,
please make sure we don't clash with the updates.
Thank you
Zuzka
7 years, 8 months
Plans for Node.js 6.x
by Stephen Gallagher
OK folks, it's Bad Decision Time.
Today, Node.js 6.0 was released. This is a significant ABI-breaking release,
which means there is no guarantee that existing modules will work with it at all.[1]
Better still, Node.js 5.x is only going to be supported until sometime this
summer, because they're aiming for the 6.x branch to become the new LTS in
October[2]. This puts us in quite a bind.
Fedora disallows major ABI changes in a stable release, so if Fedora 24 Final
ships with Node.js 5.x, we will be stuck with maintaining it until Fedora 24 EOL
(which is probably going to mean until approximately June 2017, or almost a full
year after upstream drops support). This means manually backporting any security
issues that come up without the benefit of a new version to rebase to and with
an increasing likelihood of the patches diverging from upstream.
On the flip side, the major ABI break is hitting us post-Beta Freeze for Fedora
24, which is a really terrible time to be switching to a new major version of a
language runtime (particularly since we don't actually know if any of the other
packages on the system will work with it at all).
We don't have any particularly good options here. A downgrade back to 4.x (which
will be supported until at least April 2018, well past F24 EOL) would be very
difficult at this point, since node modules may have updated to newer,
incompatible versions.
Furthermore, this came at a time where I was planning to write to the nodejs
list and let people know that due to my changing work responsibilities, I'm not
going to be able to be the primary maintainer of the main package any longer.
(I'd be able to swing the occasional minor- or point-release update, but
wrangling a major release won't be possible.)
I realize this is inopportune, but it's best if we figure out *immediately* how
we're going to handle this.
Options:
1) Downgrade back to 4.x, downgrading or dropping any modules in the collection
that don't run on that LTS version.
2) Stick with 5.x for the life of Fedora 24, handling security backports
ourselves once it hits EOL this summer.
3) Upgrade to 6.x, fixing or dropping any modules in the collection that don't
run on it yet.
I'll stick around to help with this major effort (since it's partly my fault
we're in this mess; I didn't realize that the release schedule for 5.x was so
poorly aligned with Fedora 24), but after that I'm going to need someone else to
step up and handle the primary maintenance.
I don't like any of the choices, but I'm going to suggest that option 3) may be
our best choice if we can manage it; we will want to be doing the same work for
Fedora 25/Rawhide anyway, so it's not wasted effort. Also, a lot of the node
modules in Fedora are only there because originally we needed them as
dependencies for npm. Since we recently switched to carrying the embedded npm
(and its rat's-nest of dependencies) inside the main nodejs package, we can
probably get away with breakage in a lot of the modules in the collection.
We may only need to focus in the short term on those packages that are required
by other parts of the Fedora Project (like nodejs-less, which is consumed in the
build process for many web apps).
Option 2) is the path of least resistance in the immediate short-term, but once
we run up against the upstream EOL, the maintenance burden could be prohibitive.
In theory, we could petition FESCo for permission to break ABI in the stable
release, but I wouldn't recommend it (and would probably be voting against it
were it to come from anywhere else; I'd abstain in this case due to conflict of
interest). Given that we know about the potential risk in advance, I doubt we'd
see much sympathy either. So we should realistically assume that if we choose
this option, someone is going to need to maintain the security backports (and it
will not be me, sorry).
As for Option 1)? I think someone with more knowledge of the individual modules
in Fedora (Tom Hughes? Jared Smith?) would need to figure out how many modules
would be broken if we downgraded. If it's sufficiently small, I suppose we could
epoch-bump nodejs and its virtual npm Provides: and go that route. I don't love
that we will effectively been playing yo-yo with the version in F24, but it
would be a solution...
Thoughts, other ideas? Please skip the rotten fruit; I'm on a diet.
[1]
https://github.com/nodejs/node/blob/master/CHANGELOG.md#2016-04-26-versio...
[2] https://github.com/nodejs/LTS#lts_schedule
7 years, 9 months
F24 and npm
by Tom Hughes
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/
7 years, 9 months
Intent to orphan nodejs
by Stephen Gallagher
As indicated in previous emails, my new $DAYJOB responsibilities are leaving
little time to spend on Node.js maintenance work. I'm happy to hang around and
serve as a comaintainer, but primary maintainership in Fedora should really be
picked up by someone who can dedicate more time to it.
Volunteers?
As an aside, Patches (T.C. Hollingsworth) is still listed as the primary
maintainer, but he's been non-responsive for over a year now; we should probably
request that FESCo orphan it so we can invest group::nodejs-sig as the official
owner.
7 years, 10 months
