-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Andreas Hasenack wrote: | On Wed, Jan 19, 2005 at 11:40:21AM -0600, Michael Favia wrote: | |>Apt downloads (or did) semi-large digests that contain information about |>the packages currently available on the repo (which is updated every | | | They are less in size than what yum downloads, because the pkglist file | used by apt doesn't have to list all files inside packages. yum downloads | rpm headers which can be as big as 600kb for a single package (read: tetex). | At least in my upgrade it showed me it was downloading 600kb of headers for | tetex. And afterwards it would download tetex itself, headers again of course.
Good point. Which means that using headers for dep resolution only makes bandwidth sense if:
p = size of pkglist file in apt repo y = size of yum md file n = average number of packages to install or upgrade h = average size of a header file
p < y + n * h
Make sure you include the times when no update is required in your n average. Discount that against the number of times you try to do that while the repomd/pkglist file is unchanged (which is not downloaded at that time unde reither method).
The header files are downloaded by both methods the second time so they are really a sunk cost in comparative terms. But because yum has them already perhaps it could be avoided under that mechanism. But i a=nd most people would argue that it doesnt make sense because then you lose the wholeness of the rpm for other fetching purposes unless you have 3 sections: "rpms", "headers", "headless rpms". Which drastically iincreases storage requirements and bandwidth in case of error.
| I just today tried yum from FC3 and here are my complaints (bear in mind that | these may have been addressed in a newer version: what I tested was from a | fresh FC3 install): There is a newer version that is cleaned up quite a bit.
| - yum update gives you absolutely no idea how long the download will take Does now have file ETA
| - yum update is *really* verbose. You get pages and pages of data even before | getting a list of packages which will be upgraded I agree here but it is cleaning up a bit each time and eventually there will be detractors saying "what is going on? give us more output" too. :). But generally yes i think a simplification of the pout put would be appreciated.
| - yum update can't be aborted: ctrl-c just aborts the current download and | then yum proceeds to the next one where you have to press ctrl-c again and | so on. I've noticed this as well. But actually Yum does bail out eventually normally (but does go to next mirror). Havent tested when or why.
| - after downloading lots of headers and after lots of screens filled with | information yum finally showed me what packages would be upgraded/obsoleted/removed. | Then the packages would be downloaded and, again, there was no indication of | how long that would take. The ETA displayed was for each package, and not the | whole download. Dont know this status but i think it still remains in my version.
| - yum update also doesn't tell you how big the download is in terms of size | (how many megabytes?) Real issue too.
Ill check up on the yum lists to see if i can make some usefull suggestions for output reduction/clarification and the like. Ill see what info is available and try to help bring the good info to light (Total Eta, Total Size, etc).
- -- Michael Favia michael.favia@xxxxxxxxxxxxxx Insites Incorporated http://michael.insitesinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFB8AyIBVsNYjF2rDYRAkzbAJ9WOIE+KO/oY01xeszrThHQb/j0+wCeKyTN 9m7nxlnQ7tExtE1nb8cgWh8= =p9Nu -----END PGP SIGNATURE-----
