This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 1.7.1 release date?


On Thu, Nov 19, 2009 at 07:39:21PM -0500, Charles Wilson wrote:
>[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.

This isn't really Eric's call.  If we're really contemplating releasing
1.7.1 then new functions are not going to be added.

>>> 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).

Or, you could just do this for the terminals that are currently in
termcap and create an ncurses or terminfo termcap subpackage which
contains only /etc/termcap.

Sorry to be suggesting more work for you, btw.  It just makes sense that
these ancient termcap files should be retired.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]