[CentOS] Broken repo / mirrors?

[R P Herrold]

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