Just to be clear: the trivial perl script was a demonstration that if someone wants to test such a tool, they can prototype it simply by running over a batch of actual debs and *then* come back and say what data is useful. Remember also that du is only a reflection of the blocking on the developer's disk -- not of how much space it will actually take on the user's installation, if they have a larger or smaller allocation unit (not likely, but possible, and potentially worth considering.)
Supplying an unspecified set of data in a random set of debs doesn't particularly help anyone -- if deity or whoever comes up with a useful tool, they'll *also* have much better information on what data they want, and odds are that the current du output isn't *quite* it... and thus we will have another compatibility issue. If we simply leave them out now, we don't have to deal with them until there *is* a use; and the idea Guy mentioned (of putting this all up on the web site) does *not* particularly need coordinated work. In fact, a simple "how much space will this debian install take" could be done as a cgi or javafrob, where the user selects packages and cooks up a result based on a dump like that (hmm, similar to the way Packages files are built perhaps.) Ah well, if I weren't so far behind...
