On 08/12/2011 04:14 AM, Andreas Petzold wrote:
> On Friday, August 12, 2011 12:50:12 carlopmart wrote:
>> On 08/12/2011 12:22 PM, Morten Stevens wrote:
>>> On Fri, 12 Aug 2011 11:58:19 +0200, carlopmart wrote:
>>>> Thanks Andreas, but security updates are applied?? For example, last
>>>> kernel version for SL6.0 is kernel-2.6.32-71.29.1, and for SL6.1 is
>>>> 2.6.32-131.6.1. When I will launch "yum update", kernel will updated
>>>> with 71.29.1 version or with 131.6.1 version?? It is only an example,
>>>> but I am referrering to all packages for SL6.0 version ...
>>>
>>> Hi,
>>>
>>> After yum update the kernel will be updated to 2.6.32-131.6.1. (SL6.1)
>>> Otherwise you would have to exclude the kernel update in your yum
>>> configuration.
>>>
>>> For example:
>>>
>>> /etc/yum.conf
>>> exclude=kernel*
>>>
>>> Best regards,
>>>
>>> Morten
>>
>> After read your mail, Is it correct to say: "you can't stay at SL6.0
>> with security updates applied. Always, you will be upgraded to latest
>> SL6.x + security patches", right??
>
> no. Your notion of upgrade/security fix is a bit different from RH/SL.
>
> There simply is no such thing as an updated 2.6.32-71.29.1 kernel. That's what
> kernel 2.6.32-131.6.1 is.
>
> If you install 6.0 and only do "yum update", you will never automatically go
> to 6.1. You will get security fixes, but no new features like for instance
> some new RH tech preview stuff.
>
> As I said before, if you really need a specific version of a package, you
> should exclude it in the yum config. Of course, you won't get security
> updates, since that is a version change.
>
> 	Cheers,
>
> 		Andreas

I have a suggestion for a better solution, one that may exist internally 
at Red Hat (it did at HP for HP-UX, a commercial SVR4 
release/distribution) but that does not seem to be at the community.

Some upgrades fix bugs, some upgrades fix security holes, some upgrades 
improve performance, some upgrades simply clean up highly patched code 
that is approaching "spaghetti" or "ravioli" depending upon the paradigm 
used, and some upgrades introduce new packages/utilities/drivers.

If this were made clear in a searchable data base with fixed key words, 
or the equivalent matrix, then the matter could be resolved.

An example may help to make this clear.  Suppose package foobar contains 
utility foobar1 and libraries foobarlib.so and foobarlib.a .  Suppose it 
was found, say by CERT or reports thereon, that the backwards weavil 
upside down needle (I am making up a name but this sort of name appears 
in the literature) attack exploits a memory leak in foobarlib-N.m 
allowing a root shell exploit.  This is fixed in foobarlib-X, X > N.m . 
  Moreover, a change in package foobar requires that packages muckup, 
rollover, and regurg all need to be updated as these depend upon package 
foobar and will not function with the newer, fixed package.

Were this security issue to be made clear by searchable keyword, then a 
systems maintenance person could make an informed decision as to the 
security (or driver or ... ) fixes of any package upgrade, implementing 
the exclusion of the specific package as she or he requires.  This is 
with the understanding that such an excluded update system produces a 
hybrid in some state between RHEL X.k and RHEL X.k+n, n>0 .

Note that the upgrade issues typically are made clear by a detailed 
reading of the release notes or update history of package foobar, 
usually maintained at the upstream vendor and evidently reproduced in 
some form in the SL package notes.  However, there does not seem to be a 
simple searchable keyword database.

My suggestion does not address the EOL (or EOS) issues at which epoch an 
update may be regarded as mandatory.

Yasha Karant