[sorry, either fetchmail or my ISP made me lost 30 or so emails.] The problem with bigger and bigger Packages.gz, [I thought is obvious. :-(] is,
1) It prevent many more packages to come into Debian, for example, Linux Gazette are now not present newest issues in Debian. People occasionally got fucked up by packages like anachism-doc because the precious band-width. And some occasional discussion on L10N packages to distrub others life who don't need it. 2) It don't scale. Release managment is difficult. RM in general only considering RC bugs on most of the packages he is not familiar of. ;-) Now considering mechanisms such as DIFF and RSYNC of Packages.gz 1) They're difficult to setup, though it _should_ be easier considering it's an end-user stuff. With the current state of testing, i.e., often updated Packages.gz and a more or less stable state, that people tends to update very often. 2) They have a FIX TIME problem. I.e., if you don't RSYNC or DIFF for a long time, they won't save you extra bandwidth. While my approach do. 3) They don't scale just as well. ;-) Now considering mechanism to section Packages.gz by functionality or just like Package pool does. 1) Due to the complicated Dependency problem, they're deemed to fail. ;-) Okay, now see my approach. [See my previous mail. The FINAL one. ;-)] 1) They're compatible with old tools. (Only you discuss with me!!) 2) It scales well. To release managment, and to include just as many as our hard disks permitted packages into Debian. 3) It is very easy for enduser to setup. 4) No extra burden on Developers as how frequently they should do upload. 5) No FIX TIME problem. (See above.) 6) Possibilies exist for package to provide changelog to users for their consideration to if to upload. These will help developers to avoid some fake bug reports. So why not bother discuss with me? ;-) zw