Re: 1.7.1 release date?

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

[consolidated reply]

Corinna wrote:
> On Nov 19 09:04, Charles Wilson wrote:
>> 1) Any additional functions Eric Blake thinks we should export/add
>> before 1.7.1 -- as opposed to down the road in 1.7.(N+1).  He seems to
>> find a new one every week or so.
> 
> What's your actual concern here?  Can you rephrase a bit?

Just leaving space for Eric to say "hey wait, I really think
POSIX2008/SUSv4 function 'X' should be part of cygwin-1.7.1".  If he
doesn't, fine.  If he does, but you or cgf disagree and think "X" can
wait until 1.7.2 or later, fine.  That's all.

>> 2) The terminal handling stuff Andy Koppe mentioned: making "console"
> 
> Do you mean Thomas Wolf by any chance?  He has that console patch
> in the loop which adds mouse event reporting.  The patch doesn't
> seem to interfere with current console handling, except for the
> change from ESC[9m to ESC[2m for dim.  The latter doesn't show up
> in termcap and terminfo so it shouldn't matter.
> 
> Changing the Shift-F key sequences?  Is it really worth it, given
> that they follow at least *some* standard?  I don't think so.
> 
> Everything else in this thread is either enhancement or bug fix,
> but not a visible, backward-incompatible change in behaviour.

There were "two" things I was thinking of: (a) the various stuff which
you have outlined above, but which I hadn't kept close track of, and (b)
the ^H/^? thing, that I elaborated on below.

It sounds like your opinion is, whatever cygdev *ultimately* decides
about the issues in category (a), none of them should be considered
until after 1.7.1.  I'm okay with that, but the originators of the
various patches may squawk (I think they did, downthread).  But as for
ME, I think these relatively minor tweaks can and should be delayed
until post-1.7.1.  1.7 has been held up long enough.

cgf said:
> These are not show stoppers.  In fact, given that we should be in code
> freeze right now, you could make the argument that they shouldn't be going
> in at all since they don't represent regressions.

Agree.  I basically only mentioned these items so they could be
explicitly knocked down (e.g. equivalent to marking these issues
"deferred" if we had a bugzilla)

Corinna:
> On Nov 19 09:04, Charles Wilson wrote:
>> I'm thinking of the recent discussion concerning ^H vs.
>> ^?.  I've still got a patch in my queue for terminfo, so I'd like to
>> roll that out before/simultaneously with cygwin-1.7.1; I'm pretty sure
>> there's a pending update for termcap, as well.
> 
> Right, that would make sense.

OK, I'll go review the thread and related changes in cygwin, and
evaluate the terminfo patch for an immediate rollout.

cgf wrote:
> We should consider termcap dead at this point.  I don't even have a
> /etc/termcap on my most recent Ubuntu and gentoo systems and I obviously
> haven't missed it.
> 
> Currently only tetext claims to still use termcap but I wouldn't be
> surprised to find that was not true.
> 
> So, I wouldn't mind if it was either removed or subsumed by ncurses
> since every linux distro that I know of which still has it seems to
> generate it from infotocap.

<begin tolstoy mode>

So, based on various other messages in the subthread related to termcap,
I'd recommend the following:

1) For 1.7, replace the termcap package with an _obsolete, empty one.
This would, in effect, remove
   /etc/termcap
   /usr/include/termcap.h
   /usr/lib/libtermcap.a
   /usr/share/man/man3/termcap.3
from the distro. This new, empty termcap package would NOT be part of
the 'Base' category nor the 'Libs' category: only _obsolete.  We
wouldn't even need to add an "upgrade helper" 'requires: terminfo',
because terminfo is already part of 'Base'

2) Add a post-install script to the ncurses package, which iterates thru
/usr/share/terminfo/[0-1a-f][0-1a-f]/* and calls infotocap on each of
them, generating an /etc/termcap file on-the-fly. (You don't want this
postinstall script to be part of the terminfo package, because that
would imply a dependency on ncurses; since terminfo is in 'Base' but
ncurses is not, this would implicitly pull ncurses into 'Base' and I
don't think we want to do that).

As an alternative to (2), we could make another pseudo-package like
_update-info-dir, but that's a lot of wasted effort for an
almost-obsolete file like /etc/termcap.


However, this implies (another) respin of the 1.7 ncurses package, and
I'm STILL waiting for a response from T.E.D. about the tput segfault
[*].  So, either (a) I get a response from TED soon, (b) I or somebody
else solves the tput problem, (c) I revert from ncurses patchlevel
20091024 (as used in -15) to patchlevel 20090321 (as used in -14).  (b)
isn't likely unless some ncurses expert rides to my rescue.  (a) --
well, your guess is as good as mine.  So, I lean towards (c).


[*] tput is supposedly a "non-screen" application. However, with ncurses
compiled with the options that cygwin uses, some macros force a reliance
on the "screen" pointer.  We can't change these options without breaking
the cygwin ncurses DLL ABI.  This, coupled with certain other recent
changes in upstream ncurses, means that OUR tput IS a "screen"
application -- but tput has no code to initialize the screen pointer.
I'm not sure how best to add such initialization code, so I sen the
upstream maintainer a message.  Still waiting).


(c) is not as bad as you might think.  Soon after 1.7.1 goes live, I
plan to break the ncurses ABI and move to libncurses10, and (finally!)
enable 256 color support and re-entrancy (but not full multithread
support; that's too slow. Like, factor of 10.) That is, move to what
upstream ncurses calls "ABI 6" (we currently use a bastardized,
cygwin-specific version of ABI 5. Call it ABI 5.5.)  I also plan to
release at that time a set of wide-char enabled ncurses libraries.

The point is, we won't be "stuck" at patchlevel 20090321 for very long.

</end tolstoy mode>


cgf wrote:
> But, regardless of this detail, I think that 1.7 is ready for prime
> time.  It's arguably better than 1.5 since it actually works on Vista
> and Windows 7.

OK.

--
Chuck