This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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
>>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


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]