This is inspired by Goswin's recent post about the libfoo-common/libfoo pairs of packages, which will become even more frequent with multiarch. Disclaimer: No, I won't have time to work on it - sorry, folks. And anyway, this is post sarge. Proposal: split packages into 'conventional' debs and support debs. conventional debs would be real, normal packages. support debs would - never be displayed by any frontend (except by turning on all debugging etc. etc.) - have no installation scripts - have no files in /usr/share/docs - have no package description support debs would be coupled tightly to a main package - whenever the main package is installed, the support deb is fetched, too. This is like a uber-hard versioned dependency, but additionally, specifying libfoo/testing to apt would automatically mean that libfoo-common/testing is also specified (i.e. apt pinning doesn't apply to support debs). In the libfoo/libfoo-common case, there are at least two possibilities: let the (arch dependent) libfoo package be the main package and the -common be the support package. Or have it be the other way round: arch independent main package with supporting libfoo-arch (which makes imho more sense because the Package description is also arch-independent and in this case and needs not be duplicated on all arches.) I guess, since these support debs should be so tightly coupled to their regular debs, implementing this at the dpkg level would make sense. I have certainly overlooked a huge number of issues, but I feel much of the package bloat caused by the many library package groups could be avoided in this way. greetings -- vbi -- TODO: apt-get install signify
Attachment:
pgp_Cs0ELrWBv.pgp
Description: PGP signature