[ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.34-002
Wed Dec 10 04:36:00 GMT 2014
2014-12-10 2:28 GMT+03:00 Angelo Graziosi <>:
> Corinna Vinschen wrote:
>> How nice. We have all the work and they simple grab it and don't give
>> anything back to their upstream project.
> ...the *Dark* side of free (GPL?) software... I guess..
> In any case, you could always *grab* their "pacman" manager.. Besides being
> very appealing, it would avoid the long thread [*] on cygwin-apps list..
> Why what aims to be a "..Linux feeling - on Windows" should have a "package
> manager" (setup.exe :( ) which install deps more o less silently... apt-get,
> yum, pacman, port (on OSX) (and, I sure, others) always warn the user about
> which packages are to be installed..
> Unless you adopt a 'true' package manager, I would not change the current
> behavior of setup.exe..
I'm MSYS2 maintainer. I do not understand why some of you constantly
want to throw stones in the garden of MSYS2. We are solve problems
other than Cygwin. And MSYS2 don't replace Cygwin as project. We have
small subset of Cygwin-like programs that only needed to develop
applications under Windows using mingw-w64 native toolchains. We don't
have X11 apps, daemons and many others as Cygwin have as it not need
to our work.
If you compare number of MSYS packages:
with Cygwin package list than you can see the difference. Our primary
goal is native Windows applications building with mingw-w64
toolchains. We have create lot of mingw-w64 packages:
Some patches from our project are go upstream - many not as not all
projects are open-minded. For example Python where developers always
block changes that add Mingw as build target.
Latest MSYS2 runtime sources are always present here:
Yeah I'm forgetting push latest t osf.net because I don't use it and I
don't like sf.net web-interface to repositories. Maybe need just
delete repo on sf.net and redirect page to github.
Yeah I try to stay up-to-date with current Cygwin sources to not
create by anyone other fork of Cygwin for something like MSYS3 because
of MSYS2 outdate and not supportable. Also often syncing with cygwin
sources helps with merging our changes more easily. Merging 10 commits
instead of 100 is more easily.
Our changes to Cygwin runtime as we talk in the past are not
acceptable to Cygwin upstream because have a different philosophy and
have break some posix features. About half a year ago we talk about
how integrate MSYS functionality into Cygwin upstream. As a result of
this discussion was added this code:
To try make MSYS functionality separate from original Cygwin DLL.
But as our team is small and we have our real work too, we don't have
time and in some parts necessary knowledges to finish this work. Also
I think some changes can't be easily separated into external dll.
So we open minded to incorporate with Cygwin if anyone will help with
finishing this work.
In contrast with Cygwin developers, we don't have any problems with
Arch Linux developers as we use it's latest "pacman" from git which
"is not released yet" and also have our own fork of it:
So if you want to "grab" or "rip-off" (as you wish) our pacman, feel
free to get it and use under Cygwin. We don't have any problems with
> [*] https://cygwin.com/ml/cygwin-apps/2014-12/msg00017.html
> Problem reports: http://cygwin.com/problems.html
> FAQ: http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin