Re: Subpackaging (Was: Potato now stable)
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.
Reply to: