[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

reducing the number of (user visible) packages



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: pgpxKyAEXenql.pgp
Description: PGP signature


Reply to: