[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: ruby-execjs, ruby-mail, ruby-session



On 28/07/14 03:52 PM, Cédric Boutillier wrote:
Hi Caitlin,

About ruby-session, if we don't have news about the license from
upstream before August, 10, I'll upload the package as is.

On Sun, Jul 27, 2014 at 11:55:27PM -0400, Caitlin Matos wrote:
On 27/07/14 12:44 AM, Cédric Boutillier wrote:
Here are some about ruby-execjs:
- the remark above about the debian/* tags applies here.
- I see that you imported an upstream file from the Github repository to
   create the debian/ruby-tests. It might be better to use as the
   upstream tarball the one from Github, instead of the one generated
   from the gem, and patch if needed the tests.

Ah, didn't think of that. I was mimicking what the previous packager had
done.

Just to clarify, though, should I reset (or maybe just revert) the history
and import the github version? I'm asking because I thought that was
generally frowned upon once the changes have been pushed...

There is no need to reset the history. You can just import the tarball
from github with gbp import-orig --pristine-tar. For this you should
either delete the upstream tag corresponding to the gem, or add a suffix
to the upstream version number to differentiate it from the one you
imported before (sometimes, +gh is used for that). Then you can point
the debian/watch file to look at the releases on the Github page instead
of the gemwatch one. You can also ask upstream to add the tests to the
next gem.

   The ruby-coffee-script-source package contains a copy of the
   coffee-script.js script. Instead of including the test_coffeescript in
   a begin/rescue/end block, maybe build-depend on that package and use
   the copy it contains.

I had thought about just adding the build dependency, but I wasn't sure if
that was the right approach, since it's not "mandatory". Now that I'm
thinking about it again, that seems like a silly rationale. I'll change it.

It is not needed at runtime, just for the tests. So installation of
ruby-execjs will not force the installation of ruby-coffee-script-source
for the user. You could however add ruby-coffee-script-source to the
Suggests: line as it seems that they can be used together.

Cédric


So, I've reincluded the coffeescript test, and am running into problems because it tries to open an external site. In researching the issue, I've seen quite a few bug reports saying test suites should not rely on an external connection (e.g., https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683904).

First of all, is there a policy anywhere that actually says that? I've searched through the Policy Manual, Dev guide, etc., and haven't seen anything (but I wasn't very thorough).

I see 2 solutions here: either eliminating the test completely, or bundling a coffeescript file to be used by the test suite instead of the external site. Given that the coffeescript-functionality is non-essential, I'd vote to just remove it (which is exactly what the previous packager had done, and it's possible this was the rationale all along...but there's no documentation, so I can't tell!). FWIW, when I build the package locally and not in a chroot (i.e., using debuild), the test passes.

Some opinions from more experienced packagers would be greatly appreciated!

Caitlin


Reply to: