nodejs-packagiing improvements

Jamie Nguyen j at jamielinux.com
Fri Mar 21 17:59:52 UTC 2014


On 21/03/14 00:54, T.C. Hollingsworth wrote:
> Thinking about this further, perhaps we should add a --caretify option
> or so to %nodejs_fixdep.
> 
> This option would change deps thusly (in npm-speak and rpm-speak, respectively):
> -convert '1.2.3' deps to '^1.2.3'
>     changes '==1.2.3' to '>1.2.3 <2'
> -convert '~1.2.3' deps to '^1.2.3'
>     changes '>=1.2.3 <1.3' to '>1.2.3 <2'
> -convert '1.2.x' deps to '^1.2'
>     changes '>=1.2 <1.3' to '>=1.2 <2'
> -convert '1.2' deps to '^1.2'
>     changes '>=1.2 <1.3' to '>=1.2 <2'
> -skip '1' deps, since '^1' would be functionally equivalent
>     both translate to '>=1 <2'
> -skip when one of '><=' are present, since this option makes no sense
> with such deps
> 
> This option would permit no packages to be passed as arguments (e.g.
> just '%nodejs_fixdep --caretify'), in which case it would affect all
> dependencies for which it makes sense and skip those for which it does
> not.
> 
> It would also permit a single package as an argument (e.g.
> '%nodejs_fixdep --caretify async'), in which case it would only affect
> that package, and error out instead of skipping packages when it is
> not possible.  (e.g. it will fail the build if you try to caretify a
> dependency with a '><=' in it, which is rare, but will still skip a
> plain major version dep like '1' since the dependency will be
> effectively equivalent if we appended a ^.)
> 
> I think this approach to fixing deps will be much nicer in a lot of
> cases than what we're currently doing.  If we manually '%nodejs_fixdep
> async ^1.2.3' all the time, we'll probably forget to check if the
> lower bound gets higher on us, and potentially end up with
> combinations of packages that don't work together.  This option would
> eliminate manually specifying the version in the spec, so the lower
> bound is always taken from package.json, we just adjust the upper
> bound to something that makes a lot more sense for Fedora (and the
> general ecosystem).
> 
> Make sense?  Would other packagers find this useful?

I'm not sure I'd use or promote such a feature. Currently, we are using
one or more lines of "%nodejs_fixdep" in %prep and it is very clear to
see exactly what decisions the packager has made, and how it affects the
dependencies. With just `--caretify async`, you can't tell what version
the package depends on without cross-referencing the Spec with the
package.json.

Any interested user that isn't familiar with our Node packaging macros
may want to take a look at the Spec. They can already guess what
%nodejs_fixdep async '^1.2.3' will do, but are much less likely to guess
what %nodejs_fixdep --caretify will do.

It makes sense when updating a Node package for the packager to review
the %nodejs_fixdep lines and adjust as necessary. I always diff the
package.json from the old tarball to the new tarball to see exactly what
has changed. Adding options as above might make life easier for the
packager, but may also breed carelessness, especially when using the
blanket `--caretify` for all dependencies.

As long as "%nodejs_fixdep" gains support for caret notation, I think
that's enough.


Kind regards,

-- 
Jamie Nguyen


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/nodejs/attachments/20140321/7750ee5b/attachment.sig>


More information about the nodejs mailing list