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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110227153129.ga21...@xanadu.blop.info
