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, 12 months
nodejs-packaging
by Tom Hughes
I've been working on a few updates for the nodejs-packaging tools which
I plan to build in rawhide in the next few days.
The first change is to add a --move switch to %nodejs_fixdep which
allows a dependency to be moved to a different section while preserving
it's version. So, for example:
%nodejs_fixdep --dev --move nan
Will move the nan dependency to devDependencies - this is actually a
real use case because we only need it for build but it will normally be
in the main dependencies so that that npm can build a binary module when
installing it.
You can also move things to/from optionalDependencies in the same way.
The second change is to add a --optional switch to %nodejs_symlink_deps
to allow optional dependencies to be included.
The final planned changed, and the one that may be controversial, is to
start generating Suggests dependencies for anything listed as optional
in the package.json file.
There is actually a use case for that (BZ#1290781) and I personally
think it's the right thing to do anyway, but I'm interested to hear what
other people think before I go ahead with that.
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
7 years, 10 months
npm deps broken in Rawhide
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tom, sometime over the weekend you built nodejs-osenv in Rawhide
rather than the f24-nodejs4 tag; this broke the ability to install the
older npm package on Rawhide (and is breaking other projects' builds,
such as Cockpit).
Can you look into whether npm can actually run with the new oserv and
update the dep with %nodejs_fixdep if it can? Jared and I are going to
continue working to finish the update to the new npm today, but if it
continues to take extra time, we need to try to unbreak Rawhide
concurrently.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlac+ogACgkQeiVVYja6o6OlaACgkOo2Blsm8/Lu0hVl09kZeSef
6DwAoI46GQ+SD47vNvZdrloES1xpb6sr
=5w/I
-----END PGP SIGNATURE-----
7 years, 10 months
Builds failing on EPEL7 ppc builders
by Piotr Popieluch
Hi.
Since about one week I have many failed builds of nodejs-packages on EPEL7.
The failed builds happen on ppc builders, the builds fail with:
EBUG util.py:393: Getting requirements for
nodejs-grunt-contrib-internal-0.4.9-4.el7.src
DEBUG util.py:393: --> nodejs-packaging-7-1.el7.noarch
DEBUG util.py:393: Error: Package: nodejs-packaging-7-1.el7.noarch (build)
DEBUG util.py:393: Requires: nodejs(engine) >= 0.10.12
DEBUG util.py:393: You could try using --skip-broken to work around
the problem
DEBUG util.py:393: You could try running: rpm -Va --nofiles --nodigest
https://koji.fedoraproject.org/koji/taskinfo?taskID=12048804
Which makes sense as nodejs is not available on PPC.
Do we need to set a BuildArch?
Why did this not happen before last week?
Piotr
7 years, 10 months
Re: pnemade pushed to nodejs-deep-extend (el6). "Specify exclusively
arch list as per nodejs packaging guidelines"
by Tom Hughes
On 13/01/16 11:43, notifications(a)fedoraproject.org wrote:
> From 393558883ad677a3e3b6dcb74ce42a189d712576 Mon Sep 17 00:00:00 2001
> From: Parag Nemade <pnemade(a)redhat.com>
> Date: Wed, 13 Jan 2016 10:43:33 +0530
> Subject: Specify exclusively arch list as per nodejs packaging guidelines
>
> ---
> nodejs-deep-extend.spec | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/nodejs-deep-extend.spec b/nodejs-deep-extend.spec
> index e34ec94..dbe09a0 100644
> --- a/nodejs-deep-extend.spec
> +++ b/nodejs-deep-extend.spec
> @@ -5,14 +5,14 @@
>
> Name: nodejs-%{module_name}
> Version: 0.3.2
> -Release: 1%{?dist}
> +Release: 2%{?dist}
> Summary: Recursive object extending
>
> License: MIT
> URL: https://github.com/unclechu/node-deep-extend
> Source0: http://registry.npmjs.org/%{module_name}/-/%{module_name}-%{version}.tgz
> BuildArch: noarch
> -ExclusiveArch: %{nodejs_arches} noarch
> +ExclusiveArch: %{ix86} x86_64 %{arm} noarch
This is the exact opposite of what the guidelines say surely?
The whole point of adding the nodejs_arches macro was to avoid having
the list of supported architectures embedded in all the spec files, so
that they could be extended in future without changing every spec.
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
7 years, 10 months
Check dependants before pushing to stable
by Troy Dawson
Hi,
I need to do a security update for a nodejs package, nodejs-ws to be specific.
The fix was to update to the latest package, and didn't give any other
alternatives.
So, I've got my package made, in bohdi, and tomorrow will be when the
week's wait is up.
Here's the problem, and I think many of us nodejs packages have hit it.
You update a package, every test you try works, great. You push it to
stable, and the next morning you get a pile of emails stating that you
broke all sorts of dependencies. Not that your new package can't
install, but other packages that depended on your package can no
longer install.
How can I check for dependent issues before I push to stable?
This must be a fairly common thing for Fedora but I can't seem to find
documentation for it. Everything I find talks about your new package
being able to install, not the other way around.
Troy
7 years, 10 months
Review request
by Tom Hughes
Could somebody have a look at reviewing 1274512 please, only I just
accidentally pushed a nodejs-tape update that requires it...
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
7 years, 11 months
