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)?


> 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.