Re: Pointers on Making a Cygwin CD (including source)?

["Larry Hall (Cygwin)" <reply-to-list-only-lh at cygwin dot com>]

Grant Edwards wrote:
> I need to put a Cygwin snapshot on CD[*].
>
> To that end I've been searching the mailing list archive. So
> far the scripts wirtten by Vin Shelton look like they're
> awfully close to what I want.
>
>   http://www.Cygwin.com/ml/Cygwin/2007-03/msg00606.html

This link goes nowhere for me.

> The only thing that (AFAICT) is missing is the inclusion of the
> source packages for the binary packages on the CD.  I think I
> can figure out enough zsh to do that.
>
> Before I have a go at it, is there something else I ought to be
> using instead?
>
>
>  [*] Why, you ask, do I need a CD?  Because we're distributing
>      a bunch of tools along with the Cygwin snapshot.  If we
>      distribute just the tools along with instructions on
>      installing a current Cygwin, then we'll have to worry
>      about constantly updating the tools as updates to Cygwin
>      cause them to stop working.  We've got a half-way decent
>      chance of supporting a static snapshot of Cygwin+tools,
>      but supporting the tools on top of a constantly changing
>      Cygwin base would require more resources than we have
>      available.
>
>      Even distributing the source code to the tools along with
>      a build script doesn't work, because future versions of
>      Cygwin will undoubtedly stop being able to compile the
>      tools.  For example, the previous version of the tool
>      binaries won't run on current Cygwin install. The previous
>      version of tools won't build on a current Cygwin install
>      either. FWIW, the component of the tools that causes the
>      most problems is gcc -- Cygwin stopped being able to build
>      gcc/g++ 3.2.1 sometime in 2005.  The next version of the
>      tools will use gcc/g++ 3.4.3.  That version can be built
>      on current Cygwin (as of yesterday at some point in
>      mid-morning GMT-6), but there's no guarantee that will be
>      true tomorrow or that the binaries built today will run on
>      tomorrow's "current" Cygwin.

The Cygwin DLL is meant to be backward compatible through the 1.5
series.  There will, of course, be a difference moving from 1.5 to
1.7.  After that, later 1.7 releases will be compatible with
earlier ones.  And by compatible, I mean binary compatible.  No
rebuild necessary.  If you find this is not the case with 1.7,
then that would be good to report.  Since 1.5 is a dead end, it
doesn't make allot of sense to report these kinds of problems for
it.  Of course, as you note, other packages aren't necessarily
compatible through all their versions or even their minor version
bumps.  If you need to support a particular set of Cygwin tools, it
can make sense to lock the set you're working with.  Of course, you'll
still need to contend with users that already may have Cygwin installed
and the version conflicts there.  And, as you noted, you need to
distribute the source of your application along with that for the
Cygwin DLL and the tools you're distributing to comply with the GPL,
but I expect you already know this.


--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

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