Hey Jérémy, First I would like to thank you *very much* for addressing this issue. I have a couple of comments/questions about your approach:
- I am not familiar with Git submodules. My question here is, since
uscan already knows about the source (from the gemwatch service) if
those tarballs could be used instead of those from github directly.
This would avoid duplicating logic for getting tarballs. One problem I
see with that is the generation of debian/*.gemspec. I don't know if
it is possible to generate back the .gemspec file from the
metadata.yml already included in the gemwatch tarballs.
- Currently, all the tests are run 4 times because of the 4
dh_install_commands. Maybe the best way to avoid this is to use fully
the multideb possibility of gem2deb: rewriting the
override_dh_auto_install target as follows
override_dh_auto_install:
for x in rspec rspec-core rspec-expectations rspec-mocks; do cp
debian/$$x.gemspec $$x; done
dh_auto_install
rm -rf debian/ruby-rspec-core/usr/lib/ruby/vendor_ruby/autotest/
is enough to get all the stuff installed where needed and tests are
run just once. The copied .gemspec files should be then added to the
debian/clean file. The override_dh_auto_clean can also be simplified.
Not sure about the override_dh_changelogs though.
Having this multitarball package would really improve the workflow for
preparing the ruby-rspec* packages!
Cheers,
Cédric
signature.asc
Description: Digital signature
