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

big Packages.gz file



[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



Reply to: