Re: SETUP WIZARD FOR CYGWIN?XFREE

[Christopher Faylor <cgf at redhat dot com>]

On Fri, Jul 27, 2001 at 02:25:33AM -0400, Charles Wilson wrote:
>The cygwin developers TRY to maintain forward compatibility when
>possible -- and in fact, the 1.3.1 problem you mention was a mistake. 
>The check_for_executable should have been encapsulated inside an opaque
>structure like __impure_ptr, but it was overlooked.

Actually, it was not a mistake.  I knew that I was breaking backwards
compatibility.  Putting this inside impure_ptr would have been very
difficult.  I thought I had a magical way of speeding up cygwin's
stat function but it turned out to be flawed.

We break compatibility with older DLLs all of the time.  For instance,
"I've" just added the signgam export and I'm in the process of exporting
sys_nerr and sys_errlist.

As soon as something is compiled which uses one of those
variables/functions, it will be unusable with older dlls.

>OTOH, 1.3.1 WAS released over three months ago.  cygwin-xfree ALWAYS
>requires the most recent cygwin1.dll.  Why is it so terrible to also
>require >=1.3.1 for ncurses?

It isn't.  If you've downloaded the latest package, requiring the latest
DLL is not an issue.

>As far as "ignoring" your initial bug report, that's a little harsh (and
>inaccurate) IMO.  The cygwin list at least 50 messages a day, sometimes
>more than 100.  sometimes things fall thru the cracks -- be persistent. 
>You were -- and your problems were (eventually) addressed.  as cgf said:
>> If something is broken in 1.3.2, we will try to fix it.

Right.  No one guarantees that we'll respond to every bug report.  We
eventually did respond to this one, though.  So be grateful for that.
We're all volunteers.  Who knows what other events were going on in our
lives when this urgent bug report surfaced?

>[side note: There have been a number of important fixes post 1.3.2, but
>right now the CVS version is...err, flaky.  Perhaps "the cygwin folks"
>ought to go back to a known good date, and release something and call
>THAT "1.3.3" -- but that would probably distract the developers from
>fixing the current problems and releasing what we're currently referring
>to as "1.3.3" sooner) ]

The reason that Cygwin is "flaky" is that I'm trying to fix a pretty
serious problem in 1.3.2.  I have had zero time to devote to fixing the
flakiness this week, though.

>>This seem to me, that sometime patches are made and released which have
>>some unknown side affects.  Don*t misunderstand me, I like cygwin very
>>much, but whis that I see me running in great troubles.
>
>But version skew is worse!

And, *of course* we release versions that have unknown side effects.
You might as well say that we all need oxygen to survive.  If the side
effects were *known* then we wouldn't release them.

The usual counter to that is "You should do better testing" and I would
love to have a fully fleshed out test suite and someone to run the
tests.  I don't have any of that.  What I have is people who try out
cygwin snapshots.  If they report bugs in the snapshots, I try to fix
them.  When things seem relatively stable (which they are definitely not
right now) then I release a new DLL.

>>I remember the cygwin socket bug.  I have spend one whole week with 5
>>hours a day to identifiy that cygwin must be problem, to hear that
>>usually the client code has the problem.
>
>I understand and appreciate the incredible amount of work you've put
>into your port.  Also the frustration when you identify a problem but
>folks assume you couldn't possibly know what you're talking about, so
>you have to PROVE that there REALLY was a bug.  I commisserate, really.

Consider it a rite of passage.  When Chuck reports a bug, I think "Hmm.
There must be a bug" and I investigate it.  Guess why that is?

When random cygwin mailing list person reports a bug and I am not
immediately familiar with it I usually put it in my queue to investigate
or I ask Corinna to look at it, if it is in her area of expertise.  We
have an incredible number of people reporting non-bugs, asking the same
question, making the same "suggestions".  So, bugs from unknown sources
don't get a lot of my attention.

FWIW, these days when I see email from Ralf, I put it in my priority
pile.

>>So if I imaging, how much combination of problems could be, I see me
>>supported kde 1.1.2 the whole day for the rest of my life.  For that, I
>>thing it is a lesser problem to provide a beta release with some minor
>>dlls which could be removed in every next beta release.
>
>Sure, betas -- fine by me.  But I thought you were preparing for a
>"real" release -- and THAT's what got me steamed.

Also, I don't think that it is extremely clear that the libraries will
be disappearing or that the cygwin DLL is unofficial.  It's mentioned in
your readme but we all know how many people read that.

Also, since you include a modified version of the cygwin 1.3.2 DLL, I'm
not sure why you need versions of Chuck's packages.

>>Additional I have read about a "non-new-package" of cygwin, so
>>distributing kde directly with cygwin isn*t possible at now.  As I have
>>to work on other projects in the next time too, so I have to release
>>this beta now.
>
>Right.  Beta.  Good.  Beta...

...and the whole purpose of the "no new packages" is so that we can
work out a scheme to include X11 and KDE in cygwin setup.

cgf