On Fri, 28 May 2010, Robert Heller wrote: > At Fri, 28 May 2010 16:35:44 +0200 CentOS mailing list <centos at centos.org> wrote: >> On Friday 28 May 2010, Robert Heller wrote: > It seems like there is a major snafu somewhere -- it is not just a > random mirror here or there not being up-to-date, but more of a > wholesale problem -- are we *sure* the metadata on the root server is > not broken somehow? The distribution repodata usually lags the files the way most mirrors choose to retrieve it (quite properly as that is the most 'automatable' approach); the cascade nature of the mirroring network and the lack of direct control of WHEN a mirror (or more likely, intermediate distribution mirror) BECAUSE CENTOS RELIES ON DONATED RESOURCES causes periodic skew as the system comes back in to coherency. This is one of those times If a user of CentOS cannot tolerate lag, they can choose to run a local sub-mirror, and build repodata locally in advance of mirroring repodata; the scripting is trivial If a person/entity cannot tolerate delays in the build, qa and release process CentOS follows, there are multiple write-ups on rpm building, either for selected SRPMS, or the whole shooting match that comprises the distribution. If they still connot tolerate this, they need to chill out and consider if they are testing updates on their bench before applying updates into production, or just applying the 'latest and greatest' blindly. If one needs for some emotional reason the latest and gteatest, CentOS is not likely to be a satisfying fit for that personality type. People with a testing bench have probably solved building and are probably mirroring SRPMS off the upstream anyway My little personal s390 autobuilder [a] is walking through a rebuild of C4 atm and has been for a couple weeks. It looks as though it will run about 160 hr a cycle as it converges on a selfhosting build environment; then I will check some fruit, toss out skew and rebuild it all again from my locally produced binaries, through a process of buiklding and testing several chroots. Then I will rebuild all in those chroots yet again. Then I will build for record. If you are keeping score, this is perhaps 600 hr for a clean base to build from. Then I will build the side leaves, and hope I can get say 80% success on the 2700 or so SRPMS Then I will 'bootstrap up' into a C5 series, and then a C6 series. As this is a labor of love, and a bit of art rather than a mechanical turning of a crank, I don't care -- it is ready when it 'right' to please selfhosting, trademark fixup, updater fixup, and API versions testing to match the libraries present (and absent) and at the versions that I care about If this sounds laborious and a lotlike work and not particularly fun, that would be accurate If a user of CentOS would not learn or do these steps, they need to consider buying a SLA backed subscription to the upstream's distribution to meet their time sensitivity. It really will not hurt my feelings, and I suspect, neither those of any of the core CentOS team, if there is financial support of CentOS' upstream with such subscriptions. Indeed such support helps ensure the continuation of a 'good guy' FOSS citizen resource that all of CentOS depends heavily on [1] http://twitter.com/buildmonbot A s390x, with a gig of ram allocated to it, and several LVM spindles, fed from a dedicated SRPM submirror, and out-saved through rsync to another binary result mirror -- Russ herrold