On Wed, 22 Jul 2009, Orlando Richards wrote:

> On 08/07/09 14:53, Troy Dawson wrote:
>> Orlando Richards wrote:
>>> On 02/07/09 16:16, Troy Dawson wrote:
>>>> Well ... this is a good place for the discussion.
>>>>
>>>> What *should* we do with those packages that redhat releases for the
>>>> extended support series.
>>>
>>> Do you have access to them okay? I couldn't get to the rpms (or the src
>>> rpms) using my RHN account, but we have a fairly basic level of
>>> entitlements.
>>>
>>
>> We only get our src rpm's (that we release) from their public ftp site
>> ftp://ftp.redhat.com/pub/redhat/
>> or one of it's mirrors.
>>
>>>> I'll say this upfront that it's a bit of a pain. It's a piece of cake
>>>> to look, download and build any src.rpm's that RedHat releases for
>>>> them. But the hard part is that you then have to figure out which
>>>> release those packages are for. That is the harder part. It is made
>>>> even harder by the fact that these packages usually come out a day to
>>>> a week after RedHat releases their usual security updates for the
>>>> same package. So I have no idea that there is a extra backpatched
>>>> security update for whatever it is until after I've already pushed
>>>> out the normal security update.
>>>>
>>>
>>> Hmm, I see the problem. Unless redhat have a specific announcement
>>> mechanism for the extended support chain, I can't see how to pick up
>>> on them easily. I imagine that there's quite an overhead in continuing
>>> to support N versions of SL4/5 - presumably Redhat also realise this
>>> (hence the large scale of deployment and subscription fees required to
>>> become a subscriber to the extended support service).
>>>
>>>
>>>> That being said, lets say we do figure out a way for this. How would
>>>> we get these packages out to you in a way that you could get them?
>>>
>>> How about dropping them into the SL4.7 update repository? That way,
>>> those who use 4x will skip past them (right?), but those sticking with
>>> 4.7 explicitly will still pick them up through yum.
>>
>> No, that's the problem. They will *not* get those updates even if they
>> are in the yum repository. If we take the recent kernel for example, yum
>> will see the kernel 2.6.9-89.0.3.EL and then the z kernel
>> 2.6.9-78.0.24.EL and it will think that the 89.0.3 kernel is newer, and
>> won't even show the users the z kernel.
>
> Should the 2.6.9-89 kernels not therefore be in the /48/ folder in the
> yum repository then (and, of course, /4x/)?  Is it true that,
> technically, they only exist in RH4.8 (and therefore don't belong in RH4.7)?

The 2.6.9-89 kernel is only in 48 because it was not a security errata 
kernel but the 2.6.9-89.0.3 kernel was a security errata kernel for all of 
4.x .

-Connie Sieh

>
>
>> Although ... now that I think of it, if you explicitly say a version,
>> yum will install it as long as it is newer than your kernel now ... but
>> I'm not sure about that. We'll have to test that.
>> If that is the case, and as long as people know that they want the
>> package, and what it's version is, they can install it.
>> That would make things very easy for my end.
>> Troy
>
> I'd be happy with that - but we do manage our kernels rather separately
> from the usual "yum update -y; reboot" style (which is what I use on my
> desktop machine, for instance).
>
> (ps - apologies for lag in responding, I've been on hols!)
>
>
> --
>             --
>    Dr Orlando Richards
>   Information Services
> IT Infrastructure Division
>        Unix Section
>     Tel: 0131 650 4994
>
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>