Maciej Z.enczykowski wrote: > 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] We are not talking about 5.1 and 5.2 ... those we do provide and have a process for. We are talking about (if it happens) a 5.0.1 and a 5.1.0 released simultaneously ... and then later a 5.0.2, 5.1.1, and 5.2 released simultaneously ... and further on a 5.0.3, 5.1.2, 5.2.1, 5.3 ... on and on :D The problem is that these are ALL different (if they do what they say). The whole point of the sub numbers is that the 5.0.x (5.0, 5.0.1, 5.0.2, 5.0.3 in my example) are going to be 5.0 with just security updates and things pushed into the 5.0.x tree at that point. The compiles for the 5.0.x branch would be built via the 5.0 gcc and glibc forever. Meaning that the 5.1 (or 5.2) gcc/glibc would not be used ... so anything new built in 5.1.x (or 5.2.x) and anything new built for 5.0.x are built on different gccs and glibcs and against different repos (the 5.1 stuff will be built against the new 5.1.x repo ... the 5.0 will be built against only the 5.0.x repo, etc.). As there will be different versions of libraries in the different repos, the resulting binaries will be different in some cases. Now ... I have yet to see anything like this actually done upstream ... and it is currently just something that the sales people are saying will happen. I have not seen anything in RHN implementing this in practice. So as someone suggested (Phil I think) ... let's just wait and see if it is even done (or if so, in what context it might be done) upstream. Thanks, Johnny Hughes > > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20070908/931db85c/attachment-0007.sig>