Hi Алексей,
On Jun 8 01:56, Алексей Павлов wrote:
> 2013/6/7 Corinna Vinschen wrote:
> > A final note: I'm not opposing the fork. Under the GPL it's your
> > perfect right to do so, as long as you adhere to the license
> > requirements. But that doesn't mean I have to understand it. If the
> > DLL and the tools are exactly the same and only differ by name, then,
> > what's the point? Wouldn't it make more sense to work with us on the
> > Cygwin project instead?
> >
> Some times ago we discuss about adding MSYS2 code to Cygwin on mingw-w64
> IRC. It would be more right way I think but I think you don't interesting
> in it. I'm right? That is why I create fork of Cygwin. But if it possible
> to support MSYS2 mode in Cygwin sources I think all be happy to not create
> many forks an so on.
The problem is this. So far I'm wondering what MSYS2 is about. It
doesn't add any useful functionality over Cygwin. And if so, why not
integrate it into Cygwin instead and only have one project for
everybody? JonY already maintains the mingw-w64 32 and 64 bit cross
toolchains as part of the Cygwin distro, so there's nothing missing for
those who want to create native applications.
Forking makes sense in some scenarios, especially if there's a big rift
between the development targets of the developers, or licensing
problems. But for a start, I don't see this here, unless I'm missing
something.
Granted, right now MSYS2 adds code which is entirely unacceptable for
Cygwin. For instance the symlink(2) function *copying* files, even
recursively if the target is a directory. I don't grok the reason for
this.
So here's a user or script innocently calling
ln -s /cygdrive/c/Windows /
which is something I do often to have easier access to the Windows
directory for certain tasks. But I definitely don't want a copy of the
Windows directory. If it's about compatibility with native tools, the
change still doesn't makes sense.
- Either it's Cygwin/MSYS2 tools needing the symlink, then a Cygwin
symlinks works fine,
- or you need a copy of a certain subtree, then you should have called
cp, rather than ln -s,
- or you need a Windows symlink, then you should have created a
native symlink using the new Cygwin capability to create native
symlinks using the CYGWIN=winsymlinks:native{strict} setting.
The latter would be much more feasible as default setting, while on old
pre-Vista systems, it would be much more feasible to fail gracefully, or
to use Cygwin's method to create a Windows .lnk file instead.
<emotional mode>
Other than that I'm rather puzzled as to what MSYS2 is about, other than
to duplicate developer efforts and to split communities. Apart from
your perfect right to fork, you might nevertheless understand that I'm a
bit annoyed. Especially given the code base. Me and Kai were working
hard for months to create a 64 bit version of Cygwin, and while our
Cygwin 64 bit distro is still in test mode, you simply rip off the code
and just release your own MSYS2 distro from there.
I can't help to feel exploited.
</emotional mode>
Back to the technical stuff. Again, I don't understand the reason for
the fork, please explain. What is it, codewise, you really miss in
Cygwin? What non-code problems is MSYS2 trying to fix?
Corinna
--
Corinna Vinschen
Cygwin Maintainer
Red Hat
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
