X-Spam-Check-By: sourceware.org
Subject: Re: Those nasty bundled Cygwin's
From: Sam Robb <sam DOT robb AT timesys DOT com>
To: cygwin AT cygwin DOT com
In-Reply-To: <44E9C06D.2090209@cygwin.com>
References: <c09652430608190000g5a963776o47034c2298359ca8 AT mail DOT gmail DOT com> 	 <87bqqffkxl DOT fsf AT offby1 DOT atm01 DOT sea DOT blarg DOT net> 	<44E91EE8 DOT 7090809 AT cygwin DOT com> 	 <87u046en7u DOT fsf AT offby1 DOT atm01 DOT sea DOT blarg DOT net>  <44E9C06D DOT 2090209 AT cygwin DOT com>
Content-Type: text/plain
Date: Tue, 22 Aug 2006 11:20:18 -0400
Message-Id: <1156260018.3491.118.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4)
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Mon, 2006-08-21 at 10:17 -0400, Larry Hall (Cygwin) wrote:
> Eric Hanchrow wrote:
> >>>>>> "Larry" == Larry Hall (Cygwin) <reply-to-list-only-lh at cygwin dot com> writes:
> 
> 
> <http://cygwin.com/acronyms/#PCYMTNQREAIYR>. Thanks.
> 
> 
> > 
> >     Larry> This has also been discussed before.  If you'd like to
> >     Larry> understand the options, I'd recommend reviewing the email
> >     Larry> archives for threads on this issue.
> > 
> > Thanks; I assume you mean the thread that starts with this message
> > 
> > http://article.gmane.org/gmane.os.cygwin/22549
> > 
> > ?
> 
> 
> Yes, that is one.

In case this helps... in an earlier message, you asked:

> But I was wondering -- how _is_ a vendor such as FreeNX supposed to
> distribute software that depends on Cygwin?  How can they avoid having
> their own, separate, Cygwin installation on the user's machine?

The company I work for (TimeSys [1]) provides development kits for
embedded Linux systems.  We supply an Eclipse-based IDE that runs under
Linux and Windows, as well as cross-compilers for both environments.
Under Windows, the easiest and best way for us to provide our users with
a consistent set of development tools was to build on top of Cygwin.

Very early on, we made the decision to "do the right thing" with regard
to Cygwin.  That is, instead of slinging the Cygwin DLL around all
willy-nilly [2], we built a custom Cygwin installer that is essentially
just a wrapper around the Cygwin setup program.  Our custom installer
uses a local package directory, setup.exe, and a customized setup.ini in
order to install Cygwin.

Here's what we do to prepare a Cygwin snapshot:

  - Use mkcygwget to download packages to a local directory
    (http://www.cygwin.com/ml/cygwin/2004-01/msg00056.html)
  - Cull any older packages from the downloaded package set
  - Add a couple of custom packages (binary and source, thank you) that
    provide some tools that aren't currently in the Cygwin net distro.
  - Split packages into a two hierarchies: one for binary packages, one
    for source packages. [3]
  - Munge setup.ini to put all the packages we want to automatically
    install into the 'Base' category
  - Merge all of this with the custom installer code so we can call
    setup.exe with the command-line arguments we need to have setup.exe
    install Cygwin for us.

When we do an install:

  - Determine if the user already has Cygwin installed.
  - If they do, and the version of Cygwin is < our snapshot version,
    then we offer to use the snapshot to upgrade their Cygwin install.
  - If they don't have Cygwin installed, then we offer to use the
    snapshot to create an initial Cygwin install.
  - If they choose to install or upgrade Cygwin, then we figure out
    the right command line arguments to pass to setup.exe, and let
    it do the work of installing Cygwin for us.

All of this buys us a couple of things.  First, we're able to deal
properly with end users who already have Cygwin installed - we can
either skip that phase of the install process, or offer to install or
upgrade their current version of Cygwin. 

Second, we have the ability to introduce custom packages into the setup
process.  We don't use it for anything heavy, really - we provide some
startup scripts and a build of ISC DHCP.  Still, we have the option to
provide additional packages outside of those available in the Cygwin net
distribution, if we want to or need to do so.

Third, we abrogate *all* responsibility for installing Cygwin to the
standard method (setup.exe).  If we run into problems with an install,
we can reproduce it outside of our installer shell, and report the
problem on the Cygwin mailing lists.  One of our users who has Cygwin
installed on their system has exactly what they would get if they had
used setup.exe themselves, so there's no difference between their
installation and one that someone created "by hand" using setup.exe.

This isn't to say that it wouldn't be nice if setup.exe had some
enhancements.  For example, the ability to specify a list of packages to
install on the command line would allow us to get rid of the step where
we munge setup.ini to put everything into the 'Base' category.
Similarly, it would be neat to be able to specify an additional
setup.ini that could be used to provide "extra" packages for the
installer.

Despite the fact that setup.exe isn't *exactly* what we would want [4],
we find that it does the job - and does it well enough that we haven't
significantly changed how we deal with Cygwin in over 4 years. 

-Samrobb

[1] Yes, the same TimeSys that cgf currently works for.  The way we
    install Cygwin predates his coming to the company, though.
[2] To be honest, our original installs *did* sling the Cygwin DLL
    around.  We ran into serious problems with that very quickly,
    which is why we changed over to our current method.
[3] These are used to create separate CD images, so that customers
    can choose whether or not they want to download 700 MB of source
    or not.
[4] I've been trying to find the time to work on some of this stuff
    for years... the problem with that has been that using setup.exe
    *has* worked just fine for us as-is, so there's been no impetus for
    my corporate overlords to allocate time for me to work on it :-(



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