On Thu, 2008-09-11 at 22:30 -0700, CAI Qian wrote:
> Hi,
>
> --- Seth Vidal <skvidal@xxxxxxxxxxxxxxxxx> wrote:
>
> > On Thu, 2008-09-11 at 21:17 -0700, CAI Qian wrote:
> >
> > > I think it is of yum users' interests when making language
> > decision.
> >
> > making a language decision? whatever.
> >
> > > There is another example of bad usability for handling CTRL-C,
> > >
> > > [root@localhost ~]# yum -d 10 update
> > > Config time: 0.107
> > > Yum Version: 3.2.19
> > > COMMAND: yum -d 10 update
> > > Installroot: /
> > > Reading Local RPMDB
> > > rpmdb time: 0.001
> > > Setting up Package Sacks
> > > pkgsack time: 0.003
> > > Setting up Update Process
> > > Building updates object
> > > ^C^C^C^C^C^C^C^C^C^C^C^C^C^C^Cup:Obs Init time: 0.733
> > > ^C^Cputting kpathsea in complex update
> > >
> > > ...
> > >
> > > You could see from the above, I have to hit CTRL-C more than 10
> > times
> > > in order to cancel the operation. Far more than tolerant for
> > reasonable
> > > user experience. Is it the same thing as the Python socket handling
> > > bug?
> > >
> >
> > Actually, you don't have to hit it that many times. You are hitting
> > it
> > that many times. What's happening at that particular point is that
> > the
> > rpmdb is being accessed. At which point rpm is holding the signal
> > handler that would allow that interrupt to work.
> >
>
> OK, but it makes some commands unable to be cancelled, like
>
> check-update
>
> It accessed DB, and print out things even if users don't want it
> afterwards.
>
> In addition, if a user realized that he made a bad search (too many
> results), like
>
> yum -d 10 search file
>
> and would like to cancel it later just immediately after starting to
> print out search results, he/she couldn't, and he/she had to wait a
> long time after almost all results returned back.
>
> Moreover, it is confusion and untidy to see those random backtraces
> when a user just want to cancel an yum operation.
>
> [root@localhost yum-3.2.19]# yum -d 10 search file
> ^CTraceback (most recent call last):
> File "/usr/bin/yum", line 4, in <module>
> import yum
> File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 30, in
> <module>
> import logging
> File "/usr/lib64/python2.5/logging/__init__.py", line 29, in <module>
> ^C import sys, os, types, time, string, cStringIO, traceback
> [root@localhost yum-3.2.19]# yum -d 10 search file
> ^CTraceback (most recent call last):
> File "/usr/bin/yum", line 4, in <module>
> import yum
> File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 39, in
> <module>
> from iniparse.compat import ParsingError, ConfigParser
> File "/usr/lib/python2.5/site-packages/iniparse/__init__.py", line 1,
> in <module>
> from ini import INIConfig
> File "/usr/lib/python2.5/site-packages/iniparse/ini.py", line 38, in
> <module>
> """
> KeyboardInterrupt
>
> Cai Qian
Cai Qian,
yum is an open-source project. If you feel improvements can be made to
the software because of particular use cases which affect you, write a
patch and submit it.
I seriously doubt yum will ever move away from python. Python is the
language of choice and you'll need to work around it's deficiencies. If
you find Python bugs, submit patches to the maintainer.
Coming onto a user list and acting like the sky is falling and everyone
needs to drop what they're doing and work on your problem is not going
to win you any friends. I recommend you find a way to participate in
the yum community instead of bashing it.
/Brian/
--
Brian Long | |
. | | | . | | | .
' '
C I S C O
_______________________________________________
Yum mailing list
Yum@xxxxxxxxxxxxxxxxxxxx
https://lists.dulug.duke.edu/mailman/listinfo/yum
