[Yum] Re: Horrible response to keyboardInterrupt

CAI Qian caiqian at cclom.cn
Sat Sep 13 11:32:28 UTC 2008


Hi,

--- "Mihai T. Lazarescu" <mtlagm at gmail.com> wrote:

> On Sat, Sep 13, 2008 at 01:05:13AM -0700, CAI Qian wrote:
> 
> > --- "Mihai T. Lazarescu" <mtlagm at gmail.com> wrote:
> > > That's quite unlikely.  Savvy command line users know alternate
> > > ways to stop a program, whereas GUI users won't see these
> > > problems anyway.
> > 
> > If yum provides the feature to abandon an operation, users expect
> to
> > use it, report related bugs, and someone eventually could fix those
> > bugs. It is also a feature which exists in some other package
> tools.
> > Otherwise, the document shall be added this information, says "The
> > program will not response to CTRL-C. Please use kill(1) to
> terminate
> > the program". 
> 
> I think the thread provided a pretty thorough explanation
> about the problem and it's possible fixing.  Bug fixing and
> new features are weighted by the people managing the project
> based on several criteria, among them severity, public and
> personal interests, etc.
> 
> One of the most recurring answers for those that dislike the
> free (as in no cost and as free will) maintainers of open
> source packages is: wait or do it yourself or hire someone to
> do it for you.  And I think this is a fair answer.  It's value
> added to let know of bugs but it's of no use to ask they be
> fixed according to your agenda.
> 

There is no agenda. I want to let developers aware of that it is a
painful problem for users like me. Maybe because I was a Debian user
before. I have experienced the efficient with CTRL-C in APT and the
important to be able to abandon operations when the number of available
packages have been increased a lot.

> The Ctrl-C issue of yum was worse, gradually improving
> over time.  At any moment I was a lot more more interested
> in seeing yum getting faster, stable, and feature rich rather
> than to nit pick on secondary, easy work-around shortcomings.
> I believe this way me and the community as a whole benefit most
> from the yum developers volunteered knowledge, time, and effort.
> 

It depends. If developers care about usability, it should not be the
secondary. Use kill(1) to work around the problem is not an acceptable
option from the usability point of view. In addition, if the issue has
not been solved, it is probably not scalable to provide services
(abandon, skip mirrors, rollback) by GUI tools. Please see below.

> > I have seldom used GUI tools for it. However, I guess they could
> have
> > some of those problems, if they allow to cancel operations. Which
> GUI
> > tool are you talking about?
> 
> There are several, I don't use them.  Fedora's packagekit may
> be one, yum-extender, etc.  Google may give you more accurate
> answers.
> 

I tried packagekit, but I could not bring it up. For yum-extender, it
did not allow to cancel operations. It allowed to skip mirrors though.
when I hit the 'SKIP' button when downloading packages, it simulated a
ctrl-c,

18:25:49 : Downloading Packages:
18:25:55 : skipmirror
18:25:55 : skipmirror
18:25:55 : skipmirror
18:25:55 : Failure getting
http://mirror.lib.ucdavis.edu/fedora/linux/development/x86_64/os/Packages/bubblemon-1.46-8.fc9.x86_64.rpm:

18:25:55 :   --> [Errno 15] user interrupt
18:25:55 : Trying other mirror.

Then the program aborted. Looks like a bug in yum extender though,

Checking for new repos for mirrors
Traceback (most recent call last):
  File "/usr/share/yumex/yumex.py", line 175, in
on_queueProcess_clicked
    self.setupYum()
  File "/usr/share/yumex/yumex.py", line 470, in setupYum
    self.yumbase._setupAgain()
  File "/usr/share/yumex/yumapi.py", line 129, in _setupAgain
    self.doGroupSetup()      
  File "/usr/share/yumex/yumapi.py", line 407, in doGroupSetup
    yum.YumBase.doGroupSetup(self)    
  File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 520, in
doGroupSetup
    return self._getGroups()
  File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 570, in
_getGroups
    groupfile = gzip.open(groupfile)
  File "/usr/lib64/python2.5/gzip.py", line 49, in open
    return GzipFile(filename, mode, compresslevel)
  File "/usr/lib64/python2.5/gzip.py", line 95, in __init__
    fileobj = self.myfileobj = __builtin__.open(filename, mode or 'rb')
IOError: [Errno 2] No such file or directory:
'//var/cache/yum/rawhide/comps-rawhide.xml.gz'

Cai Qian

> Mihai
> _______________________________________________
> Yum mailing list
> Yum at lists.dulug.duke.edu
> https://lists.dulug.duke.edu/mailman/listinfo/yum
> 




More information about the Yum mailing list