[avail for test] readline-4.2-1 also xpm and xpm-nox

Charles S. Wilson cwilson@ece.gatech.edu
Sun Jun 3 13:54:00 GMT 2001

Karl M wrote:
> Hi All...
> For now, could you just include the extra library in the new release?

No.  They come from different source code bases.  Yes, technically the
readline-4.1 source code is already on the cygwin mirrors -- but if you
install cygwin's readline-4.2 package (which, under your plan contains
the 4.1 DLL's) and you click 'install source' -- then you should get
BOTH sets of source code, not just the 4.2 code.  However, I don't want
to comingle the source code; I believe that's a bad idea and sets a bad
precedent.  Therefore, if the 4.1 and 4.2 source packages are to remain
separate, then the 4.1 and 4.2 binary dists must remain separate.

Anyway, I've already promised not to upgrade 4.2 from its current 'test'
status until the only official external dependent (postgres) is
ready...so what's the problem?

<note, much of the following could be considered a rant.  It's not
directed specifically at you, Karl, but you've touched a nerve...>

> To
> give time for the change over? Wouldn't that let setup-2.57 still do its
> thing correctly for almost everyone?

Yes, it would allow setup-2.57 to "do the right thing" -- if by "do the
right thing" you mean "encourage people to ignore the changes and
provide no incentive for upgrading to the bugfix/better release".  If
you *WANT* to use the old DLL's -- you can.  No problem.  I just haven't
made it brain-dead-easy to do so.  The old dll's are right there on the
web server (and probably they are right there on your current
installation).  I don't really WANT to make it easier for people to keep
them -- because that means I must continue to support obsolete variants,
and I'm not going to be around long enough to do that.

I've made it *possible* for people to keep the old dlls.  It's actually
pretty easy to do so.  It's just not automatic nor is it

Aside: Personally, I'm not all that happy about the external API changes
in readline.  I think the package version number should've been bumped
more than a minor digit.  Also, there were MASSIVE formatting changes
(and 'const' qualifiers were added all over the place) so my old patch
-- 200k of changes that were ignored by Chet -- had to be reapplied by
hand over the last four weekends.  And the response I get?  More
complaints.  So typical of this list.

> Does this approach also apply to xpm xpm-nox? Could the new release also
> include the old library for a while?

No.  The whole *POINT* of the xpm -> xpm-nox changeover was to STOP
distributing a dll that depends on external X libraries and an external
Xserver (which, you will note, are NOT themselves part of the standard
cygwin dist).  Continuing to distribute that dll kinda misses the
point.  Besides, the cygwin-xfree project distributes its own X-based
libXpm.dll.  And there are NO official packages which depend on the old
X-based dll that was a part of my older xpm package.  Therefore removing
it breaks no cygwin dependencies -- unless you've built one yourself. 
And if you're experienced enough to build an app that depends on it, you
are obviously experienced enough to either (a) follow the simple
directions and preserve the old dll (b) if you forget, download the old
package and extract the dll's by hand, or (c) rebuild your package.

(a) looks pretty easy to me...

> Then how long is a while? I think that OpenSSH deals with this issue in
> interoperability between versions. A new feature can't break
> interoperability with the previous version, but they don't keep that up
> forever. So the users have to stay somewhat current, but not up to the
> minute.

Yes, but the OpenSSH developers have more freedom than I do.  THEY OWN
THE CODE.  I do not.  Chet changed the API.  What would you have ME do? 
Change it back?  I did what I could -- made it possible, if not
idiot-proof, for the two versions to coexist.  The rest is up to you.
> Personally, I think one or two versions is long enough. If I am using a
> package with more active development going on (a faster update rate) then I
> need to update more often to stay current.

Yes, but I'm not going to be here much longer.  I doubt there will be
another update of cygwin's noX xpm package for a LONG LONG time.  Nor
ncurses.  Nor readline.

I would call for volunteers to start taking over support for some of
"my" contributions, but I know that is pointless.  There are lots of
folks who will complain about the way I've been supporting (or not) my
contributions(*), but I seriously doubt anybody has a bad enough itch to
actually step forward and take over support for those contribs
personally -- at least not while I'm still here.  It's SOOO much easier
to complain that the current maintainer isn't doing what you want or
following external release cycles fast enough, than it is to actually
BECOME the maintainer yourself.  I await a pleasant surprise -- but I
doubt one will come...

(*) these continual complaints without offers of assistance are my major
pet peeve with this community.  You have no idea how many off-list
complaints I get.  My contribs are FREE, dammit.  You're free to use
them as you like.  You're free to fork them and do your own versions. 
You're NOT free to demand that I sacrifice more of my limited time to do
things your way.  This is not Burger King -- "you can^W CAN'T have it
your way".  I'm usually pretty reasonable -- but many of the demands
I've been subjected to lately are not, and I've just about reached my
tolerance level.


Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

More information about the Cygwin mailing list