There should not be a great space usage associated with this - you only need to store one copy of each rpm/hdr file. (Unless they actually rebuild everything for 5.1... which seems very unlikely) The only actual 'extra' disk storage space would be cause by storing actual iso cd/dvd images - as mentioned many times before, this can be gotten around with jigdo. 5.0/arch/base - base 5.0 from release time 5.0/arch/updates - updates till 5.1 + security updates to 5.0 past 5.1 release [no automatic upgrade to 5.1 path] 5.1/arch/base - base 5.1 ie. Update 1 from release time 5.1/arch/updates - updates till 5.2 (+ when 5.2 comes out: security updates to 5.1 past the 5.2 release [no automatic update to 5.2 path] 5 - symlink which points to current version (ie. 5.0 currently, soon 5.1, afterwards 5.2). You want 5.0? You ask for 5.0, You want 5.newest? You ask for '5'. How do you upgrade from 5.0 to 5.1? Either change the yum repo definitions or do a manual rpm -hiv http:///....///centos-release-5.1.noarch.rpm [remember all rpms/hdrs are hardlinked to each other were identical within multiple 5.x/arch/base,update directories] Cheers, Maciej On 9/7/07, Roger Peña <orkcu at yahoo.com> wrote: > > --- Phil Schaffner <Philip.R.Schaffner at NASA.gov> > wrote: > > > On Fri, 2007-09-07 at 00:36 +0100, Karanbir Singh > > wrote: > > > pushing out each tree, as it is, for upto 3 > > sub-release deep is just plain > > > stupid. > > > > Don't pull any punches now. :-) > > > > Seems it could get to more than 3 sub-releases, > > unless the upstream > > policy is to limit it to the last 3. Witness 3.9 > > and 4.5. > > > > > So if anyone has ideas on how we can do this in a > > sane manner, please do > > > speak up :) > > > > Well, how about backing up to the basic assumptions > > before suggesting > > solutions. Just because the upstream with their > > much greater (paid) > > resources seem to be going to a M.N release scheme, > > is CentOS > > constrained to follow precisely in their footsteps? > > What's wrong with > > keeping the current scheme of following the latest > > release and > > continuing to have M as a pointer to the latest M.N > > tree? If someone > > REALLY needs the minor release[es] with associated > > updates, they can go > > to the upstream for support; however, I suspect that > > would be a > > relatively rare case. If the demand is there down > > the road, can always > > re-evaluate the policy. > I agree 100% > > but _if_ centos team whant to provide same taste as > uptream but do not have hardware to support it, I > subjest to make a public statement, explaining that > (willing to do but lack of hard) maybe CentOS get an > storage donation to provide that ;-) > > > > > So, am I sane? > I hope you are, because I agree with your criteria ;-) > > cu > roger > > __________________________________________ > RedHat Certified ( RHCE ) > Cisco Certified ( CCNA & CCDA ) > > > > ____________________________________________________________________________________ > Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. > http://sims.yahoo.com/ > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel >