Cédric Boutillier: > I have looked at the circular dependency problem you describe. > I do not see a simple solution to this, since the three packages are > used in a very non trivial manner in their respective test suite. > This situation also complicates the build of newer versions: it is > tricky to determine an order to upload the packages since test suites > may use features of non-yet-uploaded rspec packages... > […] > I am wondering if for future versions it my not be more interesting to > provide "unsplit" these packages, by providing a unique Debian package > made out of four (including ruby-rspec) upstream gem.
That last suggestion looks very hard as it breaks most of gem2deb
current assumptions.
Another idea: we stop running the test suite at build time for
ruby-rspec-mocks, ruby-rspec-expectations and ruby-rspec-core; and
instead, run all the test suites as part as building ruby-rspec.
If we tighten the dependencies and build-dependencies in ruby-rspec, we
can happily remove the circular build dependency and at the same time
keep a good level of confidence in the fact that rspec gems are in
working conditions.
What do you think?
--
Jérémy Bobbio .''`.
lu...@debian.org : :Ⓐ : # apt-get install anarchism
`. `'`
`-
signature.asc
Description: Digital signature
