[fpc] #311: Node.js guidelines update
by fedora-badges
#311: Node.js guidelines update
-----------------------------+------------------
Reporter: patches | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Guideline Draft | Version:
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------
We have a couple of changes we'd like to make to the Node.js Guidelines
after several months of refining our processes a little bit.
You can see the new draft at:
https://fedoraproject.org/wiki/User:Patches/PackagingDrafts/NodeJS
The changes include:
* I've restored the %nodejs_fixdep section included in the original
version of the draft. After reviewing the IRC logs, it seemed FPC didn't
strongly object to this, and I believe it has several advantages to patch-
based workflows. Not only is it simpler for packagers, but it also makes
them dead simple to audit later on for staleness/compliance/whathaveyou.
(`grep -r nodejs_fixdep` is just a lot easier than trying to find relevant
patches. ;-) It also makes changes to dependencies much easier to see in
git.
[https://fedoraproject.org/wiki/User:Patches/PackagingDrafts/NodeJS#Correc...
(relevant section)]
[https://fedoraproject.org/w/index.php?title=User:Patches/PackagingDrafts/...
(diff)]
* The RPM magic was recently split into it's own "nodejs-packaging" SRPM,
similar to Java. Accordingly, packages can now require "nodejs-packaging"
instead of "nodejs-devel" to reduce the number of deps dragged in at
build-time.
[https://fedoraproject.org/wiki/User:Patches/PackagingDrafts/NodeJS#BuildR...
(relevant section)]
[https://fedoraproject.org/w/index.php?title=User:Patches/PackagingDrafts/...
(diff #1)]
[https://fedoraproject.org/w/index.php?title=User:Patches/PackagingDrafts/...
(diff #2)]
[https://lists.fedoraproject.org/pipermail/nodejs/2013-April/000001.html
(list discussion)]
* The necessary ExclusiveArch line needed for Node.js packages is now
documented, including the %{nodejs_arches} macro recently added to redhat-
rpm-config for this purpose.
[https://fedoraproject.org/wiki/User:Patches/PackagingDrafts/NodeJS#Exclus...
(new section)]
[https://lists.fedoraproject.org/pipermail/nodejs/2013-May/000017.html
(list discussion)]
* A strategy for handling multiple/compatibility versions of packages that
is transparent to dependent packagers has been implemented.
[https://fedoraproject.org/wiki/User:Patches/PackagingDrafts/NodeJS#Handli...
(new section)]
[https://lists.fedoraproject.org/pipermail/nodejs/2013-June/000032.html
(list discussion)]
* The %{nodejs_default_filter} default automatic virtual provides
filtering macro (similar to Perl's) is now documented.
[https://fedoraproject.org/wiki/User:Patches/PackagingDrafts/NodeJS#Filter...
(new section)]
* A --check argument was added to %nodejs_symlink_deps simplify running
test suites in specs.
[https://fedoraproject.org/wiki/User:Patches/PackagingDrafts/NodeJS#.25check
(new section)]
* A brief mention that additional virtual provides are added for native
modules to track ABI compatibility was added.
[https://fedoraproject.org/w/index.php?title=User:Patches/PackagingDrafts/...
(diff)]
* Some minor edits were made to the installing native modules section to
reflect reality; my initial draft contained errors.
[https://fedoraproject.org/w/index.php?title=User:Patches/PackagingDrafts/...
(diff)]
* A brief note about an additional macro required to enable dependency
generation on EPEL was added.
[https://fedoraproject.org/w/index.php?title=User:Patches/PackagingDrafts/...
(diff)]
I'd like to thank the fledgling Node.js SIG, including Stephen Gallager,
Jamie Nguyen, Tom Hughes, and Stanislav Ochotnicky for their valuable bug
catching, feedback, and suggestions, without which none of this would be
possible. And, also the FPC in advance for reviewing our changes, of
course. ;-)
--
Ticket URL: <https://fedorahosted.org/fpc/ticket/311>
fpc <https://fedoraproject.org/wiki/Packaging:Committee>
Fedora Packages Collection Task Tracking
9 years, 6 months
Packaging puzzle
by Tom Hughes
I'm trying to package the mapnik module, but the latest version has a
dependency on the mapnik-vector-tile module, which turns out to be a
rather odd beast...
Basically mapnik-vector-tile has a src directory, containing some .hpp
files, and a proto directory with a protobuf definition file. When make
is run the protobuf definition is compiled to a .h and .cc pair in the
src directory.
That is it - no compiled code, no javascript, so it's not actually
loadable by node in any way.
What then happens is that the mapnik module pulls in the cpp file as
part of the so it builds - the binding.gyp in mapnik actually includes
node_modules/mapnik-vector-tile/src/vector_tile.pb.cc in it's source
file list.
Any suggestions on how to package this? Should I just package the
dependent module and have it install the src directory so that the
mapnik module can use it when building?
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
10 years, 2 months
Handling architecture limitations
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The main Node.js package supports only x86[_64] and ARM architectures,
due to these being the only supported architectures of v8. This is
causing issues with the downstream packages such as nodejs-less which
are built for EPEL6.
Is there any way to add ExclusiveArch to the
%{?nodejs_find_provides_and_requires} macro in the main node package
so that we won't try to build the modules on unsupported
architectures? It would be a lot less effort to fix that macro than it
would be to fix every node module.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlGaF3sACgkQeiVVYja6o6MlugCdGBTLzrVaz6ZQNWM7juDt0trc
krYAn0HXNxsnHewgCkyFLXC6EAUkYKSd
=PPij
-----END PGP SIGNATURE-----
10 years, 3 months
Problem with nodejs.req when node version omitted
by Jamie Nguyen
Hi!
When packaging nodejs-lodash, I noticed this error:
DEBUG: Traceback (most recent call last):
DEBUG: File "/usr/lib/rpm/nodejs.req", line 148, in <module>
DEBUG: main()
DEBUG: File "/usr/lib/rpm/nodejs.req", line 55, in main
DEBUG: deps += process_dep(req, metadata['engines']['node'])
DEBUG: TypeError: list indices must be integers, not unicode
DEBUG: Provides: nodejs-lodash = 1.3.1-1.fc19 npm(lodash) = 1.3.1
DEBUG: Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
The reason appears to be because it's package.json doesn't specify a
version for node:
"engines": [
"node",
"rhino"
],
I attached a patch for nodejs-packaging with a simple workaround, though
it's possible another approach is better.
Also, is this considered a broken/non-compliant package.json? If so,
I'll send a pull request to lodash to fix this. (I've already patched
the package.json in the package to specify '*' as the version as a
workaround.)
Kind regards,
--
Jamie Nguyen
10 years, 3 months
npm can't find README.md
by Tomas Hrcka
Hi,
when tinkering with packaged nodejs I have found that 'npm list
--global' complains about missing README.md files[1].
how do we fix this? I suggest linking README file in rpm spec and
rebuild of all affected packages.
Tomas Hrcka
[1] -- http://www.fpaste.org/19315/71546541/
===
No trees were killed to send this message, but a large number
of electrons were terribly inconvenienced.
10 years, 3 months
nodejs-packaging [was: Handling Multiple Version Scenarios]
by T.C. Hollingsworth
On Tue, Jun 4, 2013 at 6:56 PM, T.C. Hollingsworth
<tchollingsworth(a)gmail.com> wrote:
> The "inherits" module has a new breaking version out, and some modules
> are now using both versions. Jamie and I ran into something like this
> with uglify-js, and we just hacked around it for then, but doing that
> for this situation would probably take longer than just finding a nice
> way to make this easier generally, so lets do that. ;-)
This is now done as part of the Great nodejs-packaging Split we've
discussed previously. The review is here:
https://bugzilla.redhat.com/show_bug.cgi?id=974005
I went with the simple text file approach; it makes things simpler for
package maintainers and if it grows to be too unwieldy we'll need to
drastically reconsider our approach anyway...
No action is required of maintainers at this time. I believe I
already have ACLs on all the packages that will be affected by the
nodejs-inherits split once that takes place, but if not I'll bother
maintainers about that when the time comes. (All that will be
required is a simple rebuild.)
Everyone who previously had git access to the nodejs SRPM should now
have git access to nodejs-packaging upstream git as well. You can
find it in fedorahosted git:
http://git.fedorahosted.org/cgit/nodejs-packaging.git
(or `git clone git.fedorahosted.org:nodejs-packaging.git`)
There's also a clone at github if you want to subscribe to commits or
take advantage of other github features:
https://github.com/tchollingsworth/nodejs-packaging
I'll accept pull requests on github if that makes it easier for people
(not to mention it doesn't let me turn them off ;-), but otherwise
Issues and such are turned off, nor did I bother with a Trac instance
for this; it all seems like overkill. Please file bugs against the
nodejs-packaging component in bugzilla when it exists.
-T.C.
10 years, 3 months
Handling Multiple Version Scenarios
by T.C. Hollingsworth
The "inherits" module has a new breaking version out, and some modules
are now using both versions. Jamie and I ran into something like this
with uglify-js, and we just hacked around it for then, but doing that
for this situation would probably take longer than just finding a nice
way to make this easier generally, so lets do that. ;-)
Here's what I have in mind:
Packages in this situation should install in version-specific
directories under %{nodejs_sitelib}, e.g.:
uglify-js (2.x) -> %{nodejs_sitelib}/uglify-js@2
uglify-js1 (1.x) -> %{nodejs_sitelib}/uglify-js@1
The @ sign is special to npm. To get uglify-js 1 instead of 2 with
npm you'd run `npm install uglify-js@1`, so by using it here that
means you can also `npm link uglify-js@1` to bring in the RPM version.
It also prevents clashes with module names that happen to contain
numbers, and opens the door to patches to npm in the future to be
smarter here. (e.g. so even `npm link uglify-js(a)1.3` will do the
right thing as `npm install uglify-js(a)1.3` does.)
The main uglify-js package in this example would also contain a
%{nodejs_sitelib}/uglify-js -> uglify-js@2 symlink so `npm link
uglify-js` continues to work.
Now that we have a way to install them, we need a way to tell
%nodejs_symlink_deps about these special modules. There are two ways
I can think of:
1.) Make it check %{nodejs_sitelib} at build time for the existence of
these name@version directories. This requires that every package that
have dependencies experiencing this issue to BuildRequire those
dependencies, but doesn't require keeping track of these centrally as
with 2.
2.) Just keep a text file in "nodejs-packaging" with a list of these
special modules. That means updating nodejs-packaging and keeping
track of these special modules, but nothing special for package
maintainers unless they need to BuildRequire them for %check. This
text file would just be a simple newline-separated list of the npm
names of the affected modules.
There's also technically 3.) Just ship everything in versioned
directories so we don't have to worry about it. But that adds a bunch
of complexity for a 1% case and requires changing every package, so I
think that one is a no go.
I'm leaning towards 2 because that prevents packagers from having to
deal with any of this in most cases. The only one where they'd need
to be aware of it is for BuildRequires when you need the right version
of the module, in which case they'd just have to make sure they drag
in the right version, preferably with something like:
BuildRequires: npm(uglify-js) < 2
Note that the right RPM is already brought in properly regardless
thanks to the "npm(foo)" virtual provides, so that part of the problem
is already solved. The RPM name will remain irrelevant, but should
follow the standard Fedora policy for this regardless (which seems to
be just appending the major part of the version to the name).
Also, I'm only worrying about major versions here, because all npm
modules are supposed to follow the semantic versioning spec [1] which
requires a major version bump for this sort of thing to happen anyway,
so I don't see the point in overengineering this at this time.
I'm curious if anyone has any other suggestions or a recommendation
here. Thanks!
-T.C.
[1] http://semver.org/
10 years, 3 months
