On Thu, 2004-01-08 at 20:17, Lamar Owen wrote:
On Thursday 08 January 2004 01:54 pm, Jef Spaleta wrote:
Is providing a low bandwidth solution to updates really worth the extra testing and the extra mirroring..the extra drain on development and building resources. Are we saying that low bandwidth people are going to have to choose between rpmdiff packages and being able to use custom packages or Fedora Alternatives or 3rd party alternative rpms safely and effectively?
When updates exceed 100MB _ALL_ users are low bandwidth, and dialup users are locked completely out. So they don't update at all, get hacked, and blame Linux.
I'm going to be a bit of a snob and say the following:
When the updates exceed 100MB I'm _still_ not a low bandwidth user.
If you want to spend this time more effectively do the following. write the code to take librsync and rpmlib so you can sync up two dirs of rpms with entirely different file names to one, current set.
so if you have foo-1.1-1.i386.rpm on one end and foo-1.2-1.i386.rpm on the other end - an rpm-aware rsync would be able to know that foo is one package and those files should be diff'd against each other to take the bits from foo-1.1-1.i386.rpm to make foo-1.2-1.i386.rpm
This would help mirror operators quite a bit. Thereby increasing the number of mirrors and hopefully helping out the low bandwidth users by there being more mirrors.
that argument. If official mirror maintainers see potential problems with carrying the rpmdiffs...their expert opinions need to be taking with grave attention.
Absolutely. I would think mirror operators would love to reduce the load on their servers, which this would as I've envisioned it. And their bandwidth bill might even go down.
A fair number of the mirror operators don't get bandwidth bills. A lot are at universities. And the mirror operators I've run into wouldn't like a system of hundreds upon hundreds of patches let's say 2 for every potential released errata for any package. It would eat up more time on rsync and in general be a pain to deal with.
-sv