Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/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
X-Authentication-Warning: slinky.cs.nyu.edu: pechtcha owned process doing -bs
Date: Thu, 13 Mar 2003 13:45:50 -0500 (EST)
From: Igor Pechtchanski <pechtcha AT cs DOT nyu DOT edu>
Reply-To: cygwin AT cygwin DOT com
To: cygwin AT cygwin DOT com
Subject: Re: [ANNOUNCEMENT] Updated: cygwin-1.3.21-1
In-Reply-To: <20030313182938.GA1808@redhat.com>
Message-ID: <Pine.GSO.4.44.0303131345000.19751-100000@slinky.cs.nyu.edu>
Importance: Normal
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 13 Mar 2003, Christopher Faylor wrote:

> On Thu, Mar 13, 2003 AT 11:23:34AM -0600, wayne wrote:
> >On Thu, Mar 13, 2003 AT 11:53:28AM -0500, Christopher Faylor wrote:
> >> On Thu, Mar 13, 2003 AT 09:48:33AM -0500, Igor Pechtchanski wrote:
> >> ><http://cygwin.com/acronyms/#PTC> ;-)
> >> >    Igor
> >>
> >> Agh, no.  This isn't a PTC situation.
> >>
> >> Requiring specific cygwin releases is not a path we want to go down.
> >> How many times does it have to be said?  The cygwin1.dll name doesn't
> >> change because it is supposed to always *work*.  If you require a
> >> specific release you're making a mistake.
> >I already have a issue with the latest release that is why I mentioned
> >it.
>
> Sure.  Ok.  So you stabilize on a version of cygwin for your company.
> That's fine.  I don't see that as a justification for allowing all
> previous versions of cygwin to be installed.
>
> If there was a different release model where we could be insured of
> having all packages working together that would be different.  That's
> not the we we're doing things in cygwin, though.  You can argue that
> we're doing things wrong but it would certainly be confusing to allow
> the installation of cygwin 1.3.1 along with the latest version of ssh
> which doesn't work with 1.3.1.
>
> We already have that problem with the 'prev' version of cygwin but at
> least that's fairly manageable.  Allowing 27 different varieties of the
> DLL just doesn't seem like it would be a win.  I can easily envision the
> "why doesn't ssh work with 1.3.1?" messages here.
>
> I'm sure that what you're doing is essentially doing a standard "release"
> for your own internal release.  You've come up with a set of packages
> and a cygwin DLL which works nicely together.  That's fine.  I just don't
> think that this is something we want to support in setup, in general.
> cgf

Well, technically, it's already supported through custom setup.ini files.
So it's not a PTC situation after all. :-)
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha AT cs DOT nyu DOT edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor AT watson DOT ibm DOT com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
  -- /usr/games/fortune


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/