Are circular dependencies inside a source package OK?
In the pkg-ruby-extras team, we are currently discussing some big
changes in our packaging tools.
A problem arises for libraries that have a large
architecture-independent part that can be shared between the various
implementations of ruby interpreters (ruby1.8, ruby1.9.1, jruby,
rubinius), but also an architecture-dependent part that needs to be
built for each interpreter.
Ideally, we would have binary packages named like that:
ruby-foo: arch-indep part of the foo library
ruby1.8-foo: arch-dep part of the foo library, built for ruby1.8
ruby1.9.1-foo: arch-dep part of the foo library, built for ruby1.9.1
jruby-foo: arch-dep part of the foo library, built for jruby
rubinius-foo: arch-dep part of the foo library, built for rubinius
But then, we have a problem, because:
- ruby-foo need one of (ruby1.8-foo, ruby1.9.1-foo, jruby-foo,
rubinius-foo) installed to work correctly
- ruby1.8-foo, ruby1.9.1-foo, jruby-foo, rubinius-foo need ruby-foo
What we would like to do to reflect this is:
- ruby-foo depend on the implementation-specific package for the default
version of Ruby (so Depends: ruby1.8-foo)
- ruby<interpreter_version>-foo Depends: ruby-foo
However, that creates many small dependency cycles. I am under the
impression that dependency cycles are considered bad, but that we have
many of them already, and that no important part of our infrastructure
or tools really has problems with them. Also, they are limited to a
single source package here.
Is there a good reason not to do the above?