Anthony Towns <aj@azure.humbug.org.au> wrote: > First, including each architecture and source in every .deb suddenly > balloons our 3 CD set to get i386 binaries to a ~15 CD set. It also > kills non-broadband net upgrades (you *really* want to download six > copies of emacs plus all its source?). I'm not sure how you'd build > such a .deb either, without having personal access to machines of every > supported arch.
Who says I want to put all the subpackages in one package. These are individual .tar.gz on the ftp server. What I was thinking was to have them all in a directory. If I want to make i386 CDs then I just do a find on the directories and dumb the binary-*.tar.gz that I do not want. > Second, it breaks compatability with earlier versions of dpkg. If dpkg > adopts this format, then dpkg won't be able to upgrade itself. At best, > dpkg -i dpkg_blah.deb seems likely to at least lost all the optional > components (copyrights, docs, manpages...). There is that, I admit. I agreed with everything else that you said, you give a good example of how subpackaging could be implemented using dpkg. However, one of my concerns as a low bandwidth user is transferring stuff. Great, I can split my debs up into subpackages inside the deb, but what about downloading. If I do not want to download man pages, then I do not want to download man pages, if they are all together in a deb, then I have to. -- Don't worry -- shop.