[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ANNOUNCE] Vendor kernels unpakced
On Mon, 13 Aug 2001 arjan@fenrus.demon.nl wrote:
> In article <Pine.LNX.4.33.0108130920590.10511-100000@Megathlon.ESI> you wrote:
> > On Sun, 12 Aug 2001 arjan@fenrus.demon.nl wrote:
>
> >> In article <Pine.LNX.4.33.0108121607480.10511-100000@Megathlon.ESI> you wrote:
> >> > On Sat, 11 Aug 2001, Joseph Andrew Knapka wrote:
> >>
> >> >> Marco Colombo wrote:
> >>
> >> > I trust Red Hat in that 2.2.19-6.2.7 (or whatever) is better than
> >> > 2.2.19-6.2.1. Systems are simply too complex for me to believe I
> >>
> >> Well, while I recommend updating kernels when vendors release them, reading
> >> the releasenotes that go with them and deciding, based on that, if you want
> >> to upgrade....
>
> > This means that:
>
> > 1 - you perfectly understand what every single vendor patch did in the
> > old kernel, and you understand what the new patches do in the new
> > kernel;
>
> Well actually I hope I do because I put those patches there in the case of
> the Red Hat kernel. And for the people who don't want to read the patches
> (which is indeed more than 99% of the people) I also write CHANGELOGS for
> the errata releases. I _do_ expect sensible sysadmins to read those,
> especially the security ones, and see if the update applies to them.
>
> Greetings,
> Arjan van de Ven
>
So you don't expect sysadmins to run the latest official kernel, but one
among the ones you released in the past? What happens if the sysadmin
applies the same rule to all the packages? You get a random mix of
package, that no one tested in advance.
It's a more general issue. Do you really test your kernel with every
possibile combination of packages versions? E.g. do you test them
with every release of the glibc RPM or just the latest and the first
one (the one on the original CDs)?
Besides, with an average kernel update every three months, you
put many fixes into one single update (I know, it's a trade-off:
kernel updates are more dangerous that other ones, so it's nice to
pack many patches into one update), so I can't really choose the ones
I need vs. the ones I don't (ok, I can always tweak the spec file
and rebuild, but this is taking another path: on this line I can run
a vanilla or -ac kernel plus the features I need by myself).
So, I already take a set of patches all together, and I'm fine with that.
I apply the same principle to Red Hat Linux as a whole. Just like my
(vendor) kernel can be either 2.4.2-2 or 2.4.3-12, no choice of something
in the middle with only the fixes I need, my whole system can be
(a subset of) Red Hat Linux "out-of-the-box" or Red Hat Linux updated.
Any RPM combo in the middle of the two (except the ones that existed in
the past as fully updated themselves) is untested. Just imagine if
I go and comment some of the %patch lines in the kernel .spec, rebuild
and then complain to you if the system isn't stable. Even if I choose
the "right" patches, the ones I need, you won't support that kernel
since you can't test every possible combination of kernel patches.
"Sensible" sysadmins should get your kernel update as a whole, and hope
you did a good job. If they add/remove patches to the kernel, they're
putting on the "kernel hacker" hat. And are on their own, so far you're
concerned. What's wrong in having the same attitude vs. the whole
distribution? Sensible sysadmins should keep all RPMs updated. If they
go and make choices, kernel included, then they put on the "distro hacker"
hat. One thing is to choose which RPMs to install in the beginning, another
one is to make "sensible" choices on what to upgrade. I do read changelogs,
but only to decide if I need to upgrade ASAP or I can wait for the next
scheduled mantainance time. No questions whether to upgrade or not.
And BTW, Red Hat DOES put dependecies on updated RPMs even when not
strictly necessary, forcing me to upgrade more than a package, just
because they built the RPM on an updated system. And I'm fine with that
since I hope the RPMs I'm upgrading are already tested under the same
conditions.
Anyway, this is going OT. My original point was that if someone puts
an unpacked Red Hat kernel online, he/she should keep it updated.
Since RH doesn't release a kernel update so often, it won't be much
trouble. Having 2.4.2-2 online is of no use for 99% of the people.
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@ESI.it
-
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
IRC Channel: irc.openprojects.net / #kernelnewbies
Web Page: http://www.kernelnewbies.org/