Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Date: Thu, 25 Jan 2001 15:13:50 -0500 From: Christopher Faylor To: "'cygwin AT cygwin DOT com'" Subject: Re: Questions about Cygwin's setup... Message-ID: <20010125151350.A13867@redhat.com> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: "'cygwin AT cygwin DOT com'" References: <5C838890A2EDD411AFB2009027CC67091A2B78 AT cupex3 DOT rational DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.11i In-Reply-To: <5C838890A2EDD411AFB2009027CC67091A2B78@cupex3.rational.com>; from dmasters@rational.com on Thu, Jan 25, 2001 at 11:52:44AM -0800 On Thu, Jan 25, 2001 at 11:52:44AM -0800, Masterson, Dave wrote: >Well, strictly speaking, I am not a Windows system administrator -- >actually I'm a UNIX developer who happens to be working in a Windows >group at the moment. I was just considering introducing a UNIX >environment to the group (they already have a messy MKS environment) in >as low maintenance an approach as possible. My previous message was >just a couple of ideas that would make that easier. And...? This still doesn't invalidate my suggestion of seeing how other people do it in generic Windows land. >With respect to managing packages on a Windows system, what I've seen >done by others is to put the installable packages (usually copies of >the package's original CD) up on some central share somewhere and then >leave it to the individual local system admins (usually the user of >that system) to install and maintain the package on the system. In >this sense, network shares in Windows-NT are often used in the opposite >manner of NFS mounts in UNIX (ie. the shares hold centralized data >whereas the NFS mounts hold centralized programs). For the most part, >this is often forced by the licensing and installation structure of >these packages (ie. single-user, single-machine licenses). Since you're not a Windows administrator, why are you making pronouncements on how stuff is down in Windows environments? >Another post suggested a slightly kludgy way of doing what I want (I'm >still thinking about how to apply it). However, the post at least >confirms that other people want to do what I'm suggesting and have >investigated ways to workaround the current Setup.exe to do it. I don't see what the "workaround" is. I've seen people suggest ways for doing what you want to do. You need to do some extra stuff in addition to what setup.exe was designed to do. >Ultimately, though, I think >Setup.exe package should facilitate this type of a setup (or, at least, not >do anything to get in the way). I must have missed something because I don't see how setup.exe is getting in the way. Is it because it can potentially add mount info to the registry? Or is it because it can't update itself? I don't see either as very big issues. You certainly have enough tools available to you to deal with either issue without having to modify setup.exe. >In that, I think the "nice to haves" would be: > >* a command line tool that would create the necessary registry entries >for Cygwin (so that it can be put into a batch script for all the users >to run). It's already in the cygwin distribution. It is called "mount.exe". >* a "setup" package that could be kept local and updated like any other >package. Don't know what you mean here. I don't see why it is a big deal to download the setup.exe program when you need it. I guess I also don't see the real need to keep everything completely up to date with the net. Just download setup.exe on a weekly basis and use it to update your installation. cgf -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple