Re: [Mingw-users] msys localization display issues for ls.exe and less.exe

[Earnie <ea...@us...>]

Charles Wilson wrote:
> 
> #6 ... I dunno, this one is probably pretty pervasive. cygwin-1.7 made a
> LOT of changes in the permissions and ownership handling, so it might be
> difficult to "turn it off" in all the places it needs to be.
> 
> #7 Again, only affects one or two .cpp files
> 
> 
> 
> Then, there are the all the "new things" introduced in cygwin since
> 2003; some of which may be fine as they are, but others may need to be
> modified in some way for better "MSYS-ness".  Stuff like exactly HOW
> i18n and wide chars are supported in new cygwin, especially with regards
> to path-names.  Even cygwin has not yet nailed all of this down yet;
> they are currently trying to figure out the best way to handle REALLY
> long file names (>4K, up to 32K chars).
>

I started once upon a time some long time ago to make a msys-2 that
would be able to keep up with the jones' as they changed their house.
But I soon realized it was an act that was leading to futility.  There
are changes that just don't fit like the insistence on /etc/passwd and
/etc/group files.  I think the better solution is to maintain the
current fork and improve it to work as we need it to.

> 
> Alternatively, we could take a long, hard look at some of the decisions
> made in the early MSYS days, and consider if, in this new era of
> somewhat improved native win32 security (**), whether we need ALL of
> these differences from cygwin?  Maybe #4, #5, and #7 are all we *really*
> need anymore?
> 

I champion any changes that Cygwin makes that is anywhere near similar
to the changes I made in MSYS just for this reason.  However, things
like /etc/passwd and /etc/group are some of the changes that would make
it difficult to deal with, IMO.

> (**) That is, all current versions of windows are now based on the NT
> kernel, and support some modicum of security; back in the old days we
> still had to worry about win9x and its zero-security model.  New-cygwin
> no longer supports win9x at all (and neither does microsoft); should we
> worry about it any longer, for msys-2.0?)  The downside here is that you
> would no longer be able to use any-old-win32 tool to "unpack" msys
> packages, because the unpacker would have to "know" how to set the
> correct ACLs on the unpacked files; kinda like cygwin's setup.exe does.
>  However, we still want to be able to use any-old-unpacker for the MinGW
> packages...so msys itself would need to be able to "deal" with that...
> 

I think w9x is still used in too many places to dump it wholly as much
as I would like to.

> 
> 
> In any case, I really do think it would be easier to maintain any such
> msys-2.0 using a git mirror of cygwin's repo, and putting msys on a git
> branch.  That way, merges from "upstream" would be a lot simpler;
> branches are SO much easier to work with in git...
> 

A git repository may just be the ticket even for a MSYS-2 of the
existing fork.

> But, to even THINK about that, *we* need to distribute an actual msys
> port of git (and not rely *directly* on the msysgit version, which IIUC
> is actually a MinGW version bundled *with* msys).  And that needs, I
> *think*, a newer perl implementation than 5.6.1... (not sure why, but
> msysgit went thru the effort of porting 5.8.8 for SOME reason.)
> 

I moved the git binaries to my MinGW/MSYS setup and successfully used
it.  I am reviewing the patches msysgit made to MSYS and will be in
discussion with that group of developers on why some of the changes were
made.  Some are just intuitive and will go in without much problem.  One
change will affect RXVT because it gets rid of tty but I have seen no
problems with the git client and the lack of changes to MSYS.

> And higher priority than ANY of that, is to get mingw-get (CUI) support
> for package removal and package upgrades, instead of the current
> install-only behavior.  And then some sort of "real" GUI, instead of the
> goofy InnoSetup "wrapper" we have right now.
> 

Definitely.

One change you didn't mention is that MSYS sets CYGWIN options without
letting the user make a change to the chosen option.  This was done for
the ease of maintenance when a user was complaining about something not
working.  I didn't have to know what the option settings were because
they were hard coded and made testing 1000's of times easier.

-- 
Earnie
-- http://www.for-my-kids.com