Currently there is a proposal[0] to combine perl-modules and perl into a single package. perl-modules currently contains architecture independent bits, and perl contains architecture dependent bits.
FWICT, the primary argument[1] to do this is because perl and perl-modules both require the other to function properly (so a reflexive dependency or combining is reqeuired), and because circular dependencies make things complicated for dpkg and other frontends. Because this is a common situtation, where there is architecture independent data (of varying sizes) which is interdependent on architecture specific code of a particular version, reflexive dependencies are necessary.[2] Are there still tools which are in use which are unable to handle reflexive dependencies of this type?[3] If so, does the effort to fix them outweigh the effort to remove all of the circular dependencies and the resultant archive bloat?x Don Armstrong 0: http://lists.debian.org/debian-release/2009/10/msg00226.html (cc'ed to -release, but further discussion should not happen there because release isn't a discussion list.) 1: http://lists.alioth.debian.org/pipermail/perl-maintainers/2009-October/000799.html 2: The alternative is of course, archive bloat, where we have multiple copies of such data; the instant case will only contribute around 150M (3.1M*(13 archs-1)*4 releases) to the size of the archive, but I've no doubt that there are larger examples. 3: Specifically, where Package A Depends on (B=1), and Package B Depends on A; A and B are from the same source, B is architecture independent, and does not require configuration. -- The computer allows you to make mistakes faster than any other invention, with the possible exception of handguns and tequila -- Mitch Ratcliffe http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
