7:45 a.m.
Hi,
It would be nice if yum indicated somehow during the
downloading/installation process, which repository the package
comes from (e.g. Fedora Core 1 - Base).
Using different repos like Base, updates, fedora.us extras... one could
see the origin of the package.
Zoltan
7:51 a.m.
Le mer, 05/05/2004 à 14:45 +0200, Zoltan Kota a écrit :
Hi,
It would be nice if yum indicated somehow during the
downloading/installation process, which repository the package
comes from (e.g. Fedora Core 1 - Base).
Using different repos like Base, updates, fedora.us extras... one could
see the origin of the package.
And what url it's pulling the file from...
--
Nicolas Mailhot
7:53 a.m.
On Wed, 2004-05-05 at 14:51 +0200, Nicolas Mailhot wrote:
Le mer, 05/05/2004 à 14:45 +0200, Zoltan Kota a écrit :
> Hi,
>
> It would be nice if yum indicated somehow during the
> downloading/installation process, which repository the package
> comes from (e.g. Fedora Core 1 - Base).
> Using different repos like Base, updates, fedora.us extras... one could
> see the origin of the package.
And what url it's pulling the file from...
we're getting a bit busy on the screen now, aren't we?
that's a lot of content to display. It'd become a scrollfest.
the url is visible in the higher debug modes anyway if you need it.
-sv
8:07 a.m.
Le mer, 05/05/2004 à 08:53 -0400, seth vidal a écrit :
On Wed, 2004-05-05 at 14:51 +0200, Nicolas Mailhot wrote:
> Le mer, 05/05/2004 à 14:45 +0200, Zoltan Kota a écrit :
> > Hi,
> >
> > It would be nice if yum indicated somehow during the
> > downloading/installation process, which repository the package
> > comes from (e.g. Fedora Core 1 - Base).
> > Using different repos like Base, updates, fedora.us extras... one could
> > see the origin of the package.
>
> And what url it's pulling the file from...
>
we're getting a bit busy on the screen now, aren't we?
that's a lot of content to display. It'd become a scrollfest.
Well, apt does it and it's invaluable to detect mirrors which suddenly
stop working as fast as they used to.
Cheers,
--
Nicolas Mailhot
6:18 a.m.
On Wed, 2004-05-05 at 09:12, seth vidal wrote:
> Well, apt does it and it's invaluable to detect mirrors
which suddenly
> stop working as fast as they used to.
>
and I've always considered apt's output to be daunting to a new user.
-sv
The traditional solution to a problem like that would be to include a
-v/--verbose option. Any reason not to do that?
--Brad
6:19 a.m.
On Wed, 2004-05-05 at 09:12, seth vidal wrote:
> Well, apt does it and it's invaluable to detect mirrors
which suddenly
> stop working as fast as they used to.
>
and I've always considered apt's output to be daunting to a new user.
-sv
Sorry, just noticed that you already have a -d (debug) option. So same
suggestion, different option.
--Brad
8:34 a.m.
On Wed, 05 May 2004 15:07:19 +0200, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net> wrote:
Well, apt does it and it's invaluable to detect mirrors which
suddenly
stop working as fast as they used to.
Let me suggest that saying application X does something as a reason to get
that feature implemented in application Y isn't how you go about negotiating
with a developer for a feature for application Y. You need to address
the concern raised by the developer directly. In this case, the
concern was having so much information being scrolling by that its too
busy. You haven't addressed that concern. All you have said here is
why you think this specific piece of information is important enough
to give it screen real-estate, you haven't address the concern that
perhaps there isn't enough real-estate to go around.
-jef
8:51 a.m.
Le mer, 05/05/2004 à 09:34 -0400, Jeff Spaleta a écrit :
On Wed, 05 May 2004 15:07:19 +0200, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net> wrote:
> Well, apt does it and it's invaluable to detect mirrors which suddenly
> stop working as fast as they used to.
Let me suggest that saying application X does something as a reason to get
that feature implemented in application Y isn't how you go about negotiating
with a developer for a feature for application Y.
Well, I'm not asking to slavishly copy apt. I'm asking to add a feature
that I've found to be very useful when using apt. I'm sure Seth is smart
enough one can use the a* word without ending in /dev/null
You need to address
the concern raised by the developer directly. In this case, the
concern was having so much information being scrolling by that its too
busy.
I'm afraid even on a local network downloads are not so fast it's
scrolling madly. On a normal broadband link there is not much in yum to
show things are actually progressing and not stuck on a mirror.
Granted, some people might prefer a lighter reporting. But surely
putting this kind of info in debug is a bit of overkill, don't you
think ?
More than cryptic messages users hate stuff that seems stuck doing
nothing. All the daunting apt reporting at least shows magic is
currently happening. (and a lot of people do know how to interpret it
btw)
Cheers,
--
Nicolas Mailhot
9:21 a.m.
Well, I'm not asking to slavishly copy apt. I'm asking to add
a feature
that I've found to be very useful when using apt. I'm sure Seth is smart
enough one can use the a* word without ending in /dev/null
actually I have a mail filter - if any mail matches a* then it goes to
/dev/null :) - fortunately that means I don't see much mail at all.
(whoops, I won't see this one either, I just said 'all') :)
I'm afraid even on a local network downloads are not so fast
it's
scrolling madly. On a normal broadband link there is not much in yum to
show things are actually progressing and not stuck on a mirror.
The progress bars on download aren't enough information? When a mirror
fails over it says it's executing the failover.
So I think there is some progress, but only when there's an error.
Granted, some people might prefer a lighter reporting. But surely
putting this kind of info in debug is a bit of overkill, don't you
think ?
not really. The debug mode means the user can see the data that is more
beneficial to them.
More than cryptic messages users hate stuff that seems stuck doing
nothing. All the daunting apt reporting at least shows magic is
currently happening. (and a lot of people do know how to interpret it
btw)
I'm not sure when it is that yum gets stuck doing things and not
reporting any information. It might do this if you've set your
debuglevel below the default of 2 - but then that's the point of having
the lower debuglevels - their a quiet mode.
-sv
9:40 a.m.
Le mer, 05/05/2004 à 10:21 -0400, seth vidal a écrit :
> I'm afraid even on a local network downloads are not so fast
it's
> scrolling madly. On a normal broadband link there is not much in yum to
> show things are actually progressing and not stuck on a mirror.
The progress bars on download aren't enough information?
Well, with *big* rpms (openoffice.org comes to mind), no, it just takes
too long for the bar to change. A realtime download rate would help
there.
When a mirror
fails over it says it's executing the failover.
It's not always intuitive to correlate the slow download rate with the
fact a failover occurred 50 packages before - especially if yum is
running in a term one is only casually monitoring.
> More than cryptic messages users hate stuff that seems stuck
doing
> nothing. All the daunting apt reporting at least shows magic is
> currently happening. (and a lot of people do know how to interpret it
> btw)
I'm not sure when it is that yum gets stuck doing things and not
reporting any information.
It's not really stuck - it just has the appearance of being stuck, since
sometime nothing changes for a long time. Just like a stupid hourglass
cursor, having changing stuff gives the users the warm feeling something
is going on, even when the actual download rate is exactly the same as
if there were no reporting at all.
Cheers,
--
Nicolas Mailhot
10:01 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 05 May 2004 07:40, Nicolas Mailhot wrote:
Well, with *big* rpms (openoffice.org comes to mind), no, it just
takes
too long for the bar to change. A realtime download rate would help
there.
Am I missing something here? When yum is ran on the CLI, you get a REAL
TIME download indicator for each header, and then again for each rpm it
pulls down. Once it's all pulled down, it quiets down a bit as it
installs each rpm. There isn't a hash line for the actual rpm
installation (like there is w/ rpm -*vh) but thats already beyond the
point of file downloads.
- --
Jesse Keating RHCE (http://geek.j2solutions.net)
Fedora Legacy Team (http://www.fedoralegacy.org)
GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFAmQHN4v2HLvE71NURAiZMAKCR8pZ2WP6nm3VlEd7+f3ZGN3TuSwCfT2Qb
Cc6KO4Nzs08IZ29UFYgCQaY=
=eRGk
-----END PGP SIGNATURE-----
10:14 a.m.
Le mer, 05/05/2004 à 08:01 -0700, Jesse Keating a écrit :
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 05 May 2004 07:40, Nicolas Mailhot wrote:
> Well, with *big* rpms (openoffice.org comes to mind), no, it just takes
> too long for the bar to change. A realtime download rate would help
> there.
Am I missing something here? When yum is ran on the CLI, you get a REAL
TIME download indicator for each header, and then again for each rpm it
pulls down.
It's not a rate, it's ETA + size + downloaded %
All of those won't move a lot for big downloads (or slow links, or both)
There is a reason why every app that downloads stuff also displays the
rate.
Cheers,
--
Nicolas Mailhot
7:51 a.m.
On Wed, 2004-05-05 at 14:45 +0200, Zoltan Kota wrote:
Hi,
It would be nice if yum indicated somehow during the
downloading/installation process, which repository the package
comes from (e.g. Fedora Core 1 - Base).
Using different repos like Base, updates, fedora.us extras... one could
see the origin of the package.
sounds reasonable.
-sv
7342
days inactive
7342
days old
14 comments
6 participants
participants (6)
-
Brad Smith -
Jef Spaleta -
Jesse Keating -
Nicolas Mailhot -
seth vidal -
Zoltan Kota