How to detect a broken cygwin mirror? (gold star alert)

[Reini Urban]

Christopher Faylor schrieb:
> On Fri, Sep 03, 2004 at 05:58:03PM +0200, Reini Urban wrote:
>>Christopher Faylor schrieb:
>>>On Fri, Sep 03, 2004 at 01:49:40PM +0100, Dave Korn wrote:
>>>
>>>>>-----Original Message-----
>>>>>From: cygwin-owner On Behalf Of luke.kendall
>>>>>Sent: 03 September 2004 02:41
>>>>
>>>>>Cygwin-specific expertise, and move on.  The worst experiences, in my
>>>>>opinion, are like this one, that seem to come down to a broken mirror:
>>>>>our mirror rsyncing to it and breaking, and then people updating or
>>>>>installing from our broken mirror, and getting into states like my PC
>>>>>is in now.
>>>>
>>>>I don't think it's a sensible policy to be permanently chasing the
>>>>bleeding-edge of development in a production environment.  I think you
>>>>should set up your mirror with known good and stable versions of the
>>>>tools you need in your environment and then freeze it, and only update
>>>>parts of it as and when specifically needed and after testing and
>>>>change control.  IOW, I think this problem is better solved by
>>>>development methodology and management techniques than by a shell
>>>>script.
>>>
>>>Can I get YA gold star for Dave here?
>>>
>>>This is eminently sensible advice.  I was thinking the same thing but
>>>every message I started to compose on the subject did not put it as well
>>>or as non-meanly.
>>
>>I have a very different opinion on this.
> 
> 
> That's because you don't seem to be understanding what was being said.
> 
> 
>>When a mirror stops mirroring, the poor user will not be able to update 
>>any fixes to his installation, and will bother the mailing list then.
>>He will never detect that another mirror has a newer setup.ini, because 
>>mirroring is only pull, not push.
>>
>>So he will never get to any updates or fixes.
> 
> 
> Dave said that you set up YOUR OWN mirror with known, good, working
> versions of the packages and only update parts of it when needed.  That
> is the only sane way to set things up for a production environment.
> Otherwise, you are subject to the whims of every package maintainer.
> 
> If I update cygwin tomorrow and it has a bug, and you download the buggy
> cygwin to either your mirror or your local drive, you are potentially
> dead in the water.  If everyone in your organization does this, then the
> whole organization is dead in the water.
> 
> Worrying about "the best" mirror to use doesn't help.  "The best" mirror
> is not going to know that cygwin is broken.  The only way to verify that
> nothing is broken for your organization is to do controlled, staged,
> tested updates to your own local mirror.
> 
> Your local mirror needs to be maintained by someone, of course.  There
> should never be a situation where it is not being updated due to lack
> of attention.  The added delay will mean that a user may not see a bug
> fix as fast as someone who updates cygwin every fifteen minutes but,
> for an environment that entails unknowledgeable users and relies on
> not being down for long periods of time, this is the only way to do
> things.

Ah, okay. I missed the "local" mirror part.

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/