Smartrpm was (Re: Fedora Core 4)

[Andreas Hasenack]

On Thu, Jan 20, 2005 at 05:03:49PM -0500, Jeff Johnson wrote:
> >- yum update gives you absolutely no idea how long the download will take
> 
> Knowing your bw, and estimating network traffic, a priorii is no easy, 
> nor yum, problem.

Come one, even wget shows this :)

> >- yum update is *really* verbose. You get pages and pages of data even 
> >before
> > getting a list of packages which will be upgraded
> >
> 
> Verbosity increases the likelihood os diagnosing a problem. Wrapper to 
> redirect
> spewage to a log file, and invoke with -y, ain't *THAT* hard if the 
> verbosity annoys.

Why make the verbosity default? Or do you run X in verbose mode? Mozilla?  Do
you upgrade local rpm packages with rpm -Uvvh all the time?  Why are people so
worried about diagnosing packaging problems? Does this happen that often in
fedora?

> >- 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.
> >
> 
> Blame not yum for this, rpmlib runs with signals masked. If you 
> want/need more responsiveness,
> then there is a single call to check-and-exit that may need to be added 
> to rpmlib within
> some loops.

I disagree. One thing is to cancel an rpm transaction, another is to abort a
simple download.  Unless the transaction includes the download, hmm.

Anyway, yum aborts the download in progress (so it is indeed catching the
ctrl-c signal), but it then proceeds to the next download in the list and I
have to press ctrl-c again and so on. Do that with a +100Mb upgrade and you
will be annoyed really quick and wanting to kill -9 the thing.

Now, why did I even start the download then you may ask? It's because I had no
idea how large it would be (yum didn't tell me).

> >- 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.
> >
> 
> See answer to 1).

I hate to have to tell this, but other package managers show the ETA for the
whole thing just fine. They know how much they have do download, and they also
know how fast it is comming, and they know how to divide one by the other.

> >- yum update also doesn't tell you how big the download is in terms of size
> > (how many megabytes?)
> > 
> >
> 
> This could be computed/displayed, but only in units of bytes. I suspect 
> that knowing the
> size is not so useful, judging from 2 complaints regarding "how long 
> ...", but only 1 complaint
> "how large ...". YMMV.

Oh, it is useful. If I come home and yum tells me that the daily upgrade would
be 100Mb I might want to leave it running during the night instead of waiting
in front of my desktop seeing it consume my bandwidth which I could be using
for something else at that time.

After all, doesn't yum have to know what it is going to download? I'm not
talking about used space after installation (would be nice, but I wouldn't miss
it that much): it's the download size.

> If you like apt, then please, by all means, *Use apt!* No one is 
> stopping you ...

I was afraid it would piss people off. That's not what I meant. If you think
the above suggestions are crap, too bad. I was trying to help. In fact, why don't
you alias yum="strace yum" if it's that buggy that you need to debug it all the
time.

> 73 de Jeff