Re: DistroWatch Weekly, Issue 192 on Fedora
Igor Jagec escribió:
Rahul Sundaram wrote:
> Hi
> " As such, it looks like the most interesting delivery of the upcoming
> release season will be coming from the Fedora project. The developers
> have recently extended their testing cycle by a whole month to include a
> fourth test release and the extent of the new features and improvements
> in Fedora 7 seems lengthier than those in Ubuntu or Mandriva. The
> merging of Core and Extras packages into one massive software
> repository, dramatic improvements in boot speeds as well as the yum
> package management system,
>
I can agree to all of that, except the Yum thing. I haven't noticed some
Yum speed improvement on my Rawhide system I update every day. Yum is
still very very slow. SmartPM is much faster, but still more buggy than
Yum :-/
The way I see it, better leave Yum mature than tamper with
yet-another-alternative. The main advantage apt has over yum is that it
has been in development way longer than yum, and as such lots of bugs
have already been fixed. I'd say that the Yum team should focus on the
most prominent bugs in the PM before going for speed optimizations. The
worst of the problems right now (IMO) are the ones regarding to:
* Whole transaction stalled when encountering a dependency problem which
cannot be resolved. The consensus amongst users seems to be that the
program should be able to continue with which packages it can update,
and inform (whether a message on the screen or an entry in the log) of
those packages which couldn't be updated/installed and the reasons.
* Problems managing the repositories. It seems that a lot of users have
encountered this problem at one point or another. Yum will refuse to
update the packages' list giving a failed checksum error, and entering
into maddened loop fetching the primary.xml.gz from every single mirror.
The only way I've been able to workaround this problem is by cleaning
the cache. So either Yum should automatically clean the cache upon
transaction end or be done programmatically to avoid this issue, or fix
it in the given case. The problem is that for users who have no idea
what may be happening, Pirut and Pup simply don't respond, and there is
no way to find out what's going on other than running Yum from the
command line.
* Another "problem" many other users complain about is that from time to
time (and even with the "fastestmirror" plug-in installed) yum will
connect to *extremely* slow mirrors (we're talking about mirrors from
which data is fetched @1-2Kb/s), from which large updates (like OOo) are
a nightmare to even think about. I'm not sure why some times this
happens, I've only encountered this "problem" a couple of times my self
(in all the time I've been using Fedora, which is from Yarrow).
* Also the issue of Yum being unable to read the local package list,
which (as the other problems) stalls Yum. This is more dramatic (just as
the mirror primary.xml.gz problem, and mirror looping) when yumupdatesd
is running, because the instance of yumupdatesd renders yum unusable
(Pirut, Pup and yum CLI included) unless the process is stopped. This is
particularly problematic for users who may not have a clue what's going
on, nor how to see what's happening or know how to fix it. In most cases
running "yum clean all" is enough, though I've seen some cases where
manual download of an updated yum package is required (especially in new
FC5 installations, I've seen this thus far in 6 new FC5 installations,
where yum stalls while trying to run 'yum update').
From what I see in Bugzilla pretty much all of these problems have been
reported in one way or another, and for some of these issues, there
doesn't seem to be a clear reason why it even happens (at least I don't
have the slightest idea). However the point of yum and the relevance of
YUM for the distribution, is of extreme relevance and importance, as
(I'd be willing to say) it is if not *the* most, one of the _most_
*important* pieces of software in the distribution, and the one new
users have the most problems with. This renders proper Yum operation
*critical* for Fedora. It's worked fine until now, and it should only
improve and squash whatever bugs remain, then focus on the speed issue.