Are circular dependencies inside a source package OK?

[Lucas Nussbaum <lucas@lucas-nussbaum.net>]

Hi,

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
  installed

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?

- Lucas