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@yahoo.com wrote:
--- Phil Schaffner Philip.R.Schaffner@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@centos.org http://lists.centos.org/mailman/listinfo/centos-devel