Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Fri, 3 Sep 2004 12:13:41 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: How to detect a broken cygwin mirror? (gold star alert) Message-ID: <20040903161341.GE9839@trixie.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <20040903014127 DOT 6FBDC8454B AT pessard DOT research DOT canon DOT com DOT au> <20040903144029 DOT GA8992 AT trixie DOT casa DOT cgf DOT cx> <4138948B DOT 8090400 AT x-ray DOT at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4138948B.8090400@x-ray.at> User-Agent: Mutt/1.4.1i 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. cgf -- 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/