On Mon, Mar 27, 2006 at 08:13:33AM -0600, Troy Dawson wrote:
> Hi Axel,
> Yes, I believe you are right.

Thanks, I already adjusted ATrpms' updates to be the sum of errata and
bugfixes.

> The one catch is the bugfix rpm's, and it's actually something that I 
> wanted to bring up in a e-mail conversation, either here or ons 
> scientific-linux-users.
> 
> What exactly should go into the bugfix area.
> 
> Now for SL 305, it was easy.  I just put in all the rpm's that are going 
> to be in 307, that arn't included in the errata.
> 
> But for the older releases, the question is how much do we put in.
> I'll use SL 303 for an example, but this applies to all the older releases.
> 
> For SL 303, do I just put in all the rpm's in SL 304, that aren't in the 
> errata?  Or do I just put in all the rpm's from SL 307 that aren't in 
> the errata?  Or do I do a cumulative work, meaning, I put in all the SL 
> 304 bugfix, then all the SL 305 bugfix, and then all the SL 307 bugfix?
> 
> Any ideas anyone?

I have always been using the full latest available updates be that
errata, bugfixes or feature enhancements, so I may be off here, but
isn't the model of RHEL<N>U<M> (aka SL <N>0<M>) to feed security and
major bugfix errata to the rhn channels only keeping minor bugfixes
and feature enhancements until RHEL<N>U<M+1> is released? But the
moment RHEL<N>U<M+1> is out the rhn channels get flooded by it, so in
fact as a RHEL user you don't really have a choise of staying with
RHEL<N>U<M> and have only security bugfixes. In this case I'd say do
it like the upstream vendor and flood the SL users, too. Otherwise
you'll never know whether furture security errata of RHEL<N>U<M+1>
really apply to RHEL<N>U<M> w/o previously appling all updates
including minor bugfixes and feature enhancements.

Otherwise if I'm wrong and RHEL provides a set of security errata only
areas/channels for past "update"-releases, then I'd take that set.


> Troy
> 
> Axel Thimm wrote:
> >Hi,
> >
> >Michael pointed out that ATrpms' hierarchy had some desyncing with SL
> >content (not the ATrpms' mirror of SL, that's a 1-1 mapping, of
> >course).
> >
> >I've read through the list's archive, and found that I missed the
> >bugfixes repo. I'm fixing this at ATrpms, but just to make sure, can
> >you verify these mappings? Thanks!
> >
> >release rpms:  
> >ftp.scientificlinux.org/linux/scientific/$versionx/$arch/SL/RPMS
> >release srpms: 
> >ftp.scientificlinux.org/linux/scientific/$versionx/SRPMS/vendor/original
> >	       ftp.scientificlinux.org/linux/scientific/$versionx/SRPMS
> >update rpms:   
> >ftp.scientificlinux.org/linux/scientific/$versionx/$arch/errata/SL/RPMS
> >	       ftp.scientificlinux.org/linux/scientific/$versionx/$arch/errata/bugfix/RPMS
> >update srpms:  
> >ftp.scientificlinux.org/linux/scientific/$versionx/SRPMS/vendor/errata
> >               ftp.scientificlinux.org/linux/scientific/$versionx/SRPMS
> >
> 
> 

-- 
Axel.Thimm at ATrpms.net