Smartrpm was (Re: Fedora Core 4)

[Michael Favia]

-----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 at insitesinc.com
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-----