Hi Gilles,
I'm looking into this more indepth, and I do appreciate you bringing
this to my attention. Here's my first glance thoughts.
I updated to yum 3.0.3 (and corresponding rpm's) because it was much
faster and more reliable than the 3.0.0 that was in the original beta.
Yes, from everything I've read, RedHat will be using Yum.
*BUT*
This bugzilla entry is for yum-updatesd.
We never used this in any of our previous S.L., and I actually had not
planned on using it for this one. I was planning on using the cron job
script that we use in S.L. 4.x. It works quite well, and I didn't see
the need to change. (Why fix what isn't broken.)
Although we currently have the yum-updatesd in the distribution, it
isn't installed by default, and currently isn't installable except by
kickstart or after the install (it isn't in the comps.xml).
Anyway, thanks for bringing this to my attention.
Troy
Gilles Detillieux wrote:
> Hi, Troy.
>
> I gather from your last e-mail that either Red Hat has chosen to include
> yum-3.0.3, or you have. I tried to see what exactly Red Hat is
> including in its RHEL5 beta, but it seems I can't get at that
> information without being a member of the Red Hat Network. It's not
> clear to me from your list of "Changed RPMS compared to vendor" below
> whether including yum 3.0.3 was your decision or theirs. Either way,
> I'd suggest that this would be a mistake. The version of yum included
> in Fedora Core 4 and SL4/RHEL4 (i.e. v. 2.4), while not perfect, was at
> least reasonably reliable and with one simple command ("chkconfig yum
> on") you could ensure that your system would automatically update itself
> and tell you what updates were installed.
>
> Now, have a look at this as-yet unresolved bugzilla entry for yum 3.0.3
> in Fedora Core 6:
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212507
>
> In all my years of looking after Red Hat/Fedora Linux systems, I have
> never seen a bug report with so many comments, so many users on the CC
> list, nor open for so long with no resolution. Now, if this were some
> trivial and dispensable component, one could excuse the lack of
> solution, remove the package, and get on with life. But this is a
> pretty critical piece of code! Being able to reliably update your Linux
> system, and know what updates are being installed, is vitally important
> to maintaining a secure system. Yet this program leaks memory, doesn't
> log updates (when it does actually install them), hangs, and generally
> makes system updates a pain. The only workaround so far is to install
> an unofficial RPM package to restore the cron job update functionality
> of earlier Fedora releases, then modify that cron job for verbose output
> so it won't lose it's syslog capability. I've tried to walk through the
> code in yum to see why in this version the syslog output seems to be
> tied to the debugging output, and why you can't seem to get one without
> the other, but I've found the code to be almost indecipherable when
> trying to follow how that option gets passed along to the various
> components of the program. I never bothered trying to look at or fix
> the yum-updatesd code, having given up on it many months ago. Given the
> lack of progress on resolving these outstanding issues, I'm inclined to
> believe the maintainers are similarly baffled by this code.
>
> That Red Hat has not made more of an issue of this is similarly
> baffling. This is a serious bug that's been around for the entire life
> of Fedora Core 6, yet Red Hat seems content to unleash this mess in
> Fedora 7 and RHEL5 with still no hope of resolving this. This is hardly
> enterprise-class code! I don't know whether you have any say in what
> Red Hat does with RHEL5, and whether you can draw attention to this
> problem (the bug report above seems to have escaped the attention of
> some key decision makers and I don't know who they are), but if you
> can't get them to correct this problem, I'd recommend that you at least
> try to provide something better in Scientific Linux 5.0 for updating the
> system.
>
> I've been waiting eagerly for SL5's official release, to update some of
> my production systems in our neuroscience labs, but this issue, if still
> unresolved, could prove to be a show-stopper for us. I'd be very
> appreciative if you could look into this matter.
>
> Thanks for your time,
> Gilles
> Systems Analyst
> Spinal Cord Research Centre
>
> On Thursday, Mar 8, 2007, at 11:01 CST, Troy Dawson wrote:
>> The Scientific Linux developers are pleased to announce our "Second
>> Alpha Release" of Scientific Linux 5.0
>>
>> This is not for production use.
>> This release will change *dramatically* before the final release.
>> You have been warned.
>>
>> Below are the changes from The Upstream Vendor Beta 2 release
>> Things marked with an * are changed from our first alpha release.
>>
>> -Connie Sieh
>> -Troy Dawson
> ...
>> -------------------------------------------------------------------------
>> Changed RPMS compared to vendor
>> -------------------------------------------------------------------------
>> * yum-3.0.3-2.SL.noarch.rpm
>> * yum-conf-50-0.3.rolling.SL.noarch.rpm
>> * yum-metadata-parser-1.0.3-1.el5.x86_64.rpm
>> * yum-updatesd-3.0.3-2.SL.noarch.rpm
>> gdm-2.16.0-19.SL.1.i386.rpm
>>
>> There are minimal changes compared to the "vendor" release. We have
>> changed the "rpms" that are required to be changed. These changes are
>> defined by the "vendor".
>
> --Gilles R. Detillieux E-mail: <[log in to unmask]>
> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/
> Dept. Physiology, U. of Manitoba Winnipeg, MB R3E 3J7 (Canada)
>
--
__________________________________________________
Troy Dawson [log in to unmask] (630)840-6468
Fermilab ComputingDivision/LCSI/CSI DSS Group
__________________________________________________
|
