Mail Archives: cygwin/2003/03/13/13:29:38
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
--
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/
- Raw text -