perl and perl-modules; reflexive dependencies vs. archive bloat
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
Reply to: