Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1167041 - Review Request: nodejs-tern - JavaScript code analyzer for deep, cross-editor language support
Summary: Review Request: nodejs-tern - JavaScript code analyzer for deep, cross-editor...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tom Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1167032
Blocks: nodejs-reviews
TreeView+ depends on / blocked
 
Reported: 2014-11-22 21:51 UTC by Gerard Ryan
Modified: 2014-11-28 18:39 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-11-28 18:39:56 UTC
tom: fedora-review+
gwync: fedora-cvs+


Attachments (Terms of Use)

Description Gerard Ryan 2014-11-22 21:51:36 UTC
Spec URL: https://galileo.fedorapeople.org/nodejs-tern/0.7.0-1/nodejs-tern.spec
SRPM URL: https://galileo.fedorapeople.org/nodejs-tern/0.7.0-1/nodejs-tern-0.7.0-1.fc22.src.rpm
Description: Tern is a stand-alone, editor-independent JavaScript analyzer that can be used
to improve the JavaScript integration of existing editors.
Fedora Account System Username: galileo

Comment 1 Tom Hughes 2014-11-23 13:57:12 UTC
This needs a BuildRequire on npm(acorn) for the tests.

Comment 2 Gerard Ryan 2014-11-23 15:10:35 UTC
Spec URL: https://galileo.fedorapeople.org/nodejs-tern/0.7.0-2/nodejs-tern.spec
SRPM URL: https://galileo.fedorapeople.org/nodejs-tern/0.7.0-2/nodejs-tern-0.7.0-2.fc22.src.rpm

Thanks for taking this review Tom.

(In reply to Tom Hughes from comment #1)
> This needs a BuildRequire on npm(acorn) for the tests.

I've added that now.

Comment 3 Tom Hughes 2014-11-23 16:35:33 UTC
Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed



===== MUST items =====

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: License field in the package spec file matches the actual license.
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[-]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: Package consistently uses macros (instead of hard-coded directory names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[!]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[x]: Package is not known to require an ExcludeArch tag.
[-]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 256000 bytes in 16 files.
[x]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least one
     supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[x]: If (and only if) the source package includes the text of the license(s)
     in its own file, then that file, containing the text of the license(s)
     for the package is included in %doc.
[x]: Package requires other packages for directories it uses.
[x]: Package must own all directories that it creates.
[x]: Package does not own files or directories owned by other packages.
[x]: All build dependencies are listed in BuildRequires, except for any that
     are listed in the exceptions section of Packaging Guidelines.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package use %makeinstall only when make install' ' DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package do not use a name that already exist
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as provided
     in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local

===== SHOULD items =====

Generic:
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[-]: If the source package does not include license text(s) as a separate file
     from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[?]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[-]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: %check is present and all tests pass.
[x]: Packages should try to preserve timestamps of original installed files.
[x]: Sources can be downloaded from URI in Source: tag
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: Dist tag is present (not strictly required in GL).
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: SourceX is a working URL.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[x]: Spec use %global instead of %define unless justified.

===== EXTRA items =====

Generic:
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Spec file according to URL is the same as in SRPM.


Rpmlint
-------
Checking: nodejs-tern-0.7.0-2.fc22.noarch.rpm
          nodejs-tern-0.7.0-2.fc22.src.rpm
nodejs-tern.noarch: W: only-non-binary-in-usr-lib
nodejs-tern.noarch: W: dangling-symlink /usr/lib/node_modules/tern/node_modules/glob /usr/lib/node_modules/glob
nodejs-tern.noarch: W: dangling-symlink /usr/lib/node_modules/tern/node_modules/minimatch /usr/lib/node_modules/minimatch
nodejs-tern.noarch: E: zero-length /usr/lib/node_modules/tern/lib/jsdoc.js
nodejs-tern.noarch: W: dangling-symlink /usr/lib/node_modules/tern/node_modules/acorn /usr/lib/node_modules/acorn
2 packages and 0 specfiles checked; 1 errors, 4 warnings.




Rpmlint (installed packages)
----------------------------
# rpmlint nodejs-tern
nodejs-tern.noarch: W: only-non-binary-in-usr-lib
nodejs-tern.noarch: W: dangling-symlink /usr/lib/node_modules/tern/node_modules/glob /usr/lib/node_modules/glob
nodejs-tern.noarch: W: dangling-symlink /usr/lib/node_modules/tern/node_modules/minimatch /usr/lib/node_modules/minimatch
nodejs-tern.noarch: E: zero-length /usr/lib/node_modules/tern/lib/jsdoc.js
nodejs-tern.noarch: W: dangling-symlink /usr/lib/node_modules/tern/node_modules/acorn /usr/lib/node_modules/acorn
1 packages and 0 specfiles checked; 1 errors, 4 warnings.
# echo 'rpmlint-done:'



Requires
--------
nodejs-tern (rpmlib, GLIBC filtered):
    nodejs(engine)
    npm(acorn)
    npm(glob)
    npm(minimatch)



Provides
--------
nodejs-tern:
    nodejs-tern
    npm(tern)



Source checksums
----------------
http://registry.npmjs.org/tern/-/tern-0.7.0.tgz :
  CHECKSUM(SHA256) this package     : 5aa65a3381f9d74f74cc44a9e9071e92e46d1873e52f5bc4b829b54bac02a45c
  CHECKSUM(SHA256) upstream package : 5aa65a3381f9d74f74cc44a9e9071e92e46d1873e52f5bc4b829b54bac02a45c


Generated by fedora-review 0.5.2 (63c24cb) last change: 2014-07-14
Command line :/usr/bin/fedora-review -m compton-rawhide-x86_64 -b 1167041
Buildroot used: compton-rawhide-x86_64
Active plugins: Generic, Shell-api
Disabled plugins: Java, C/C++, Python, fonts, SugarActivity, Ocaml, Perl, Haskell, R, PHP, Ruby
Disabled flags: EXARCH, EPEL5, BATCH, DISTTAG

Comment 4 Tom Hughes 2014-11-23 16:36:51 UTC
Moslty look good. The files in the defs directory should maybe go in %{_datadir} though and then be symlinked into the node library directory.

Also does it make sense to package anything in bin? or the emacs files as a subpackage?

Comment 5 Gerard Ryan 2014-11-23 17:50:28 UTC
(In reply to Tom Hughes from comment #4)
> The files in the defs directory should maybe go in
> %{_datadir} though and then be symlinked into the node library directory.

Ok, so the files inside defs/ should go directly into %{_datadir}/tern/ and then symlinked from there back to %{nodejs_sitelib}/tern/defs/ ?

> Also does it make sense to package anything in bin?

Hmm, actually yes tern, condense, and from_ts from bin/ should probably all be packaged. bin/test comes with the module as downloaded from npm...should I just include the entire dir?

> or the emacs files as a subpackage?

I was looking at that initially, but I must have gotten distracted. I've never created a package for emacs (even my first js/nodejs packaging started yesterday!). A subpackage seems like a good approach, but reading the packaging guidelines for emacs[1], this sounds like "Case 2", for which it says:

> Where a package's principal functionality does not require (X)Emacs, but the package also includes some auxiliary Elisp files to provide support for the package in (X)Emacs, these should be included in the main package which will need to Require the emacs-filesystem and/or xemacs-filesystem packages.

So, is a subpackage acceptable, or would the main package need to have the files & depend on emacs-filesystem? If subpackage, is nodejs-tern-emacs acceptable? Or do you know of a way that we could have a subpackage that looks like an emacs package, like emacs-tern or something?

Thanks again for reviewing, and any help you can provide.

Purely for context: I'm mainly just packaging this as a dependency for the Eclipse plugin that bundles it, that I need as a new dependency for another Eclipse plugin.

[1] https://fedoraproject.org/wiki/Packaging:Emacs

Comment 6 Tom Hughes 2014-11-24 11:22:28 UTC
(In reply to Gerard Ryan from comment #5)
> (In reply to Tom Hughes from comment #4)
> > The files in the defs directory should maybe go in
> > %{_datadir} though and then be symlinked into the node library directory.
> 
> Ok, so the files inside defs/ should go directly into %{_datadir}/tern/ and
> then symlinked from there back to %{nodejs_sitelib}/tern/defs/ ?

I think we have generally been using %{_datadir}/%{name} which would be nodejs-tern rather than tern, but that is the general idea, yes. The actual guidelines are here:

https://fedoraproject.org/wiki/Packaging:Node.js#Installing_Modules

and just say "arch independent content other than JavaScript code" should be in %{_datadir}.

> > Also does it make sense to package anything in bin?
> 
> Hmm, actually yes tern, condense, and from_ts from bin/ should probably all
> be packaged. bin/test comes with the module as downloaded from npm...should
> I just include the entire dir?

I would leave out test I think. You may also want to symlink to some of them from %{_bindir}, especially tern as I think the emacs extensions will need to be able to start that.

> So, is a subpackage acceptable, or would the main package need to have the
> files & depend on emacs-filesystem? If subpackage, is nodejs-tern-emacs
> acceptable? Or do you know of a way that we could have a subpackage that
> looks like an emacs package, like emacs-tern or something?

I think you're right that case 2 applies and you should require emacs-filesystem and do it in the main package.

Note you'll need to drop a file (tern-init.el or something) in site-start.d with the autoload line form http://ternjs.net/doc/manual.html#emacs in it. You won't need the add-to-list for load-path as /usr/share/emacs/site-lisp will already be on the path.

> Thanks again for reviewing, and any help you can provide.

No problem. I do have a few node package reviews of my own open if you feel like reciprocating ;-)

Comment 7 Gerard Ryan 2014-11-24 21:03:43 UTC
Spec URL: https://galileo.fedorapeople.org/nodejs-tern/0.7.0-3/nodejs-tern.spec
SRPM URL: https://galileo.fedorapeople.org/nodejs-tern/0.7.0-3/nodejs-tern-0.7.0-3.fc22.src.rpm

(In reply to Tom Hughes from comment #6)
> I think we have generally been using %{_datadir}/%{name} which would be
> nodejs-tern rather than tern, but that is the general idea, yes.

Done.

> I would leave out test I think. You may also want to symlink to some of them
> from %{_bindir}, especially tern as I think the emacs extensions will need
> to be able to start that.

Done.

> I think you're right that case 2 applies and you should require
> emacs-filesystem and do it in the main package.
> 
> Note you'll need to drop a file (tern-init.el or something) in site-start.d
> with the autoload line form http://ternjs.net/doc/manual.html#emacs in it.
> You won't need the add-to-list for load-path as /usr/share/emacs/site-lisp
> will already be on the path.

Done (and tested that "M-x tern-mode" works fine in emacs).

> No problem. I do have a few node package reviews of my own open if you feel
> like reciprocating ;-)

Of course! I'll have a look at the tracker bug this week & see what ones I can do for you. Thanks again! :)

Comment 8 Tom Hughes 2014-11-24 22:30:53 UTC
Looks good - the only thing I can see is that the .el files (not the site-start.d one, but the other two) need to be byte compiled:

https://fedoraproject.org/wiki/Packaging:Emacs#Manual_byte_compilation

Comment 9 Gerard Ryan 2014-11-25 21:22:10 UTC
Spec URL: https://galileo.fedorapeople.org/nodejs-tern/0.7.0-4/nodejs-tern.spec
SRPM URL: https://galileo.fedorapeople.org/nodejs-tern/0.7.0-4/nodejs-tern-0.7.0-4.fc22.src.rpm

(In reply to Tom Hughes from comment #8)
> Looks good - the only thing I can see is that the .el files (not the
> site-start.d one, but the other two) need to be byte compiled:

Done, thanks.

Comment 10 Tom Hughes 2014-11-25 21:28:29 UTC
The elisp sources should included along with the byte compiled files: 

https://fedoraproject.org/wiki/Packaging:Emacs#Packaging_of_source_elisp_files

Other than that it looks good now, so I'll approve it.

Comment 11 Gerard Ryan 2014-11-25 22:12:57 UTC
(In reply to Tom Hughes from comment #10)
> The elisp sources should included along with the byte compiled files: 
> 
> https://fedoraproject.org/wiki/Packaging:
> Emacs#Packaging_of_source_elisp_files
> 
> Other than that it looks good now, so I'll approve it.

Thanks a lot. I'll be sure to include those files before import.

I'll have a look at your open reviews tomorrow hopefully!

Comment 12 Gerard Ryan 2014-11-25 22:13:43 UTC
New Package SCM Request
=======================
Package Name: nodejs-tern
Short Description: JavaScript code analyzer for deep, cross-editor language support
Owners: galileo
Branches: f21
InitialCC:

Comment 13 Gwyn Ciesla 2014-11-26 12:39:52 UTC
Git done (by process-git-requests).

Comment 14 Gerard Ryan 2014-11-28 18:39:56 UTC
I built this in Rawhide yesterday: http://koji.fedoraproject.org/koji/buildinfo?buildID=595842

Closing, thanks.


Note You need to log in before you can comment on or make changes to this bug.