¿Cómo se relacionan msys, msys2 y msysgit entre sí?

He estado buscando, pero no puedo encontrar una descripción detallada de lo que está sucediendo con estas 3 versiones de MSYS. (Es completamente posible, simplemente no sé qué buscar). Entiendo que MSYS es un puerto mínimo de herramientas de Linux para soportar el desarrollo usando MinGW, pero no tengo clara la relación entre los tres o el equipos que los desarrollaron / mantienen.

Cuestiones particulares a tratar:

• ¿Cuáles están en desarrollo activo? (En particular, ¿MSYS está muerto y MSYS2 activo?)
• ¿Cuál es la relación entre los grupos que los mantienen? (En particular, ¿el equipo de MSYS creó MSYS2?)
• ¿Msysgit solo usa uno de los otros, o tienen su propia rama de MSYS?
• ¿Alguno de estos es compatible entre sí?
• ¿Hay algún problema de compatibilidad con versiones particulares de Windows para alguno de estos?
• ¿Uno proporciona características principales sobre el otro?

Descargo de responsabilidad: soy un desarrollador de MSYS2

Si bien MSYS no está muerto, yo diría que tampoco se ve muy saludable. Es un proyecto iniciado por el equipo de MinGW hace muchos años como un tenedor de Cygwin que nunca estuvo a la altura de Cygwin.

msysgit es una bifurcación de una versión un poco más antigua de MSYS con algunos parches personalizados, versiones antiguas de Bash y Perl y un puerto nativo de Git.

MSYS2 es un proyecto iniciado por Alexey Pavlov del equipo mingw-builds (que son los empaquetadores oficiales de las cadenas de herramientas MinGW-w64) como una bifurcación reciente de Cygwin que rastrea de cerca el último Cygwin para que no quede desactualizado. Alexey adelantó los viejos parches de MSYS y agregó algunos de los suyos.

Además de proporcionar las herramientas Unix necesarias para compilar software nativo, el objetivo declarado de MSYS, portamos el administrador de paquetes Pacman de Arch Linux . Pacman es más que solo administrar paquetes binarios (aunque lo hace muy bien). Tiene una infraestructura de creación de software llamada makepkg que permite la creación de recetas (PKGBUILD y archivos de parche) para la creación de software.

En mi humilde opinión, la adopción de Pacman cambia las cosas significativamente para el desarrollo de código abierto en Windows. En lugar de que todos pirateen sus propios scripts de shell a medida para construir software de una manera incompatible, los paquetes ahora pueden depender de otros paquetes y archivos PKGBUILD y los parches asociados se pueden usar como referencia para construir nuevos PKGBUILD. Está tan cerca de un sistema Linux como un Windows (nativo) puede obtener (Arch Linux en particular) y permite una actualización simple de todos los paquetes instalados.

Apuntamos a Windows XP SP3 como mínimo y admitimos Windows de 32 bits y 64 bits. Le pedimos que nunca mezcle MSYS2 con msys o msysgit. Pacman se utiliza para administrar todo el sistema y, como tal, los archivos de los otros sistemas causarán conflictos.

También intentamos actualizar nuestros parches a los proyectos que construimos y solicitamos activamente contribuciones de otros proyectos de código abierto. Esperamos que a otros les resulte fácil trabajar con nosotros.

Nuestro sitio web principal está en SourceForge , y contiene enlaces a nuestros repositorios PKGBUILD. También tenemos un sitio de instalación más fácil de usar en GitHub .

Siéntase libre de unirse a nosotros en IRC (oftc # msys2) si desea más información.

Git 2.8 (marzo de 2016) incluye una confirmación muy detallada que explica la importancia de msys2 para el nuevo git-for-windows que reemplazó a msysgit a principios de 2015 .

Ver commit df5218b (13 de enero de 2016) por Johannes Schindelin ( dscho) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit 116a866 , 29 de enero de 2016)}

Durante mucho tiempo, Git para Windows se quedó atrás de las versiones 2.x de Git porque los desarrolladores de Git para Windows querían dejar que ese gran salto coincidiera con un salto muy necesario de MSys a MSys2.

Para comprender por qué este es un problema tan grande, debe tenerse en cuenta que muchas partes de Git no están escritas en C portátil, sino que Git se basa en un shell POSIX y Perl para estar disponible .

Para admitir los scripts, Git para Windows tiene que enviar una capa de emulación POSIX mínima con Bash y Perl , y cuando el esfuerzo de Git para Windows comenzó en agosto de 2007, este desarrollador decidió usar MSys, una versión simplificada de Cygwin .
En consecuencia, el nombre original del proyecto era "msysGit" (que, lamentablemente, causó mucha confusión porque pocos usuarios de Windows saben acerca de MSys, y menos aún).

Para compilar el código C de Git para Windows, también se utilizó MSys: tiene dos versiones del compilador C de GNU:

• uno que se vincula implícitamente a la capa de emulación POSIX,
• y otro que apunta a la API Win32 simple (con algunas funciones convenientes incluidas).

Los ejecutables de Git para Windows se crean utilizando este último y, por lo tanto, en realidad son solo programas Win32. Para discernir los ejecutables que requieren la capa de emulación POSIX de los que no, los últimos se denominan MinGW (Minimal GNU para Windows) cuando los primeros se denominan ejecutables de MSys .

Sin embargo, esta dependencia de MSys también generó desafíos:

• algunos de nuestros cambios en el tiempo de ejecución de MSys, necesarios para admitir mejor Git para Windows, no se aceptaron en sentido ascendente, por lo que tuvimos que mantener nuestra propia bifurcación.
• Además, el tiempo de ejecución de MSys no se desarrolló aún más para admitir, por ejemplo, UTF-8 o 64 bits, y aparte de la falta de un sistema de gestión de paquetes hasta mucho más tarde (cuando mingw-getse introdujo), muchos paquetes proporcionados por el proyecto MSys / MinGW van a la zaga de los respectivos versiones de código fuente, en particular Bash y OpenSSL.

Durante un tiempo, el proyecto Git para Windows intentó remediar la situación al tratar de construir versiones más nuevas de esos paquetes, pero la situación rápidamente se volvió insostenible, especialmente con problemas como el error Heartbleed que requiere una acción rápida que no tiene nada que ver con el desarrollo de Git para Windows más lejos.

Felizmente, mientras tanto surgió el proyecto MSys2 ( https://msys2.github.io/ ), y fue elegido para ser la base del Git para Windows 2.x.
Al igual que MSys, MSys2 es una versión simplificada de Cygwin, pero se mantiene activamente actualizada con el código fuente de Cygwin .
Por lo tanto, ya es compatible con Unicode internamente, y también ofrece el soporte de 64 bits que anhelamos desde el comienzo del proyecto Git para Windows.

MSys2 también portó el sistema de gestión de paquetes Pacman de Arch Linux y lo usa mucho . Esto brinda la misma conveniencia a la que los usuarios de Linux están acostumbrados desde yumo apt-get, y a los que los usuarios de MacOSX están acostumbrados desde Homebrew o MacPorts, o usuarios de BSD desde el sistema Ports, a MSys2: un simple pacman -Syuactualizará todos los paquetes instalados a las versiones más recientes actualmente disponible.

MSys2 también es muy activo, por lo general, proporciona actualizaciones de paquetes varias veces por semana.

Todavía requirió un esfuerzo de dos meses para llevar todo a un estado donde la suite de prueba de Git pasa, muchos meses más hasta que se lanzó el primer Git oficial para Windows 2.x, y todavía hay un par de parches que esperan su envío a los respectivos proyectos ascendentes . Sin embargo, sin MSys2, la modernización de Git para Windows simplemente no habría sucedido .

Este compromiso sienta las bases para soportar las compilaciones de Git basadas en MSys2.

En los comentarios , se hizo la pregunta en enero de 2016:

Dado que Git para Windows ya está basado en MSYS2, ¿los binarios que no dependen de la capa de emulación están disponibles como un paquete MSYS2?

Ray Donnelly respondió en ese momento:

Todavía no nos hemos fusionado por completo, no. Aunque estamos trabajando en eso.

Pero ... madz señala que a principios de 2017, ese esfuerzo no funcionó.
Ver:

• Alexpux/MSYS2-packages PR 786
• git-for-windows/git número 284

El problema es que no puedo aportar cambios que den como resultado un nuevo tiempo de ejecución de msys2 de manera oportuna.
Sin embargo, no es un gran problema: solo mantendré la bifurcación de Git para Windows ejecutándose indefinidamente.

La wiki por lo tanto menciona ahora (2018):

Git para Windows creó algunos parches para msys2-runtime que no se han enviado en sentido ascendente. (Esto se había planeado, pero se determinó en el número 284 que probablemente no sucedería).
Esto significa que debe instalar Git para Windows msys2-runtime personalizado para tener un git totalmente funcional dentro de MSYS2.

Tenga en cuenta que, desde que confirmó aeb582a9 (Git 2.22, Q2 2019), el proyecto Git para Windows inició el proceso de actualización a una versión de tiempo de ejecución MSYS2 basada en Cygwin v3.x.

mingw: permite construir con un tiempo de ejecución MSYS2 v3.x

Recientemente, el proyecto Git para Windows inició el proceso de actualización a una versión en tiempo de ejecución MSYS2 basada en Cygwin v3.x.

Esto tiene la notable consecuencia de que $(uname -r)ya no informa una versión que comienza con "2", sino una versión con "3".

Eso rompe nuestra compilación, ya que df5218b ( config.mak.uname: soporte MSys2, 2016-01-13, Git v2.8.0-rc0) simplemente no esperaba que la versión informada uname -rdependiera de la versión subyacente de Cygwin: esperaba que la versión informada coincidiera con el " 2 "en" MSYS2 ".

Así que invirtamos ese caso de prueba para probar cualquier otra cosa que no sea ​​una versión que comience con "1" (para MSys).
Eso debería protegernos para el futuro, incluso si Cygwin termina lanzando versiones como 314.272.65536.

Git 2.22 (Q2 2019) preparará para el futuro una prueba contra una actualización de MSYS2 runtime v3.x series.

Ver commit c871fbe (07 de mayo de 2019) por Johannes Schindelin ( dscho) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit b20b8fe , 19 de mayo de 2019)}

t6500(mingw): use el PID de Windows del shell

En Git para Windows, utilizamos el MSYS2 Bash que hereda un modelo PID no estándar de la capa de emulación POSIX de Cygwin: cada proceso MSYS2 tiene un PID de Windows normal y, además, tiene un PID MSYS2 (que corresponde a un proceso sombra que emula Manejo de señal estilo Unix).

Con la actualización al tiempo de ejecución MSYS2 v3.x, ya no se puede acceder a este proceso OpenProcess()oculto, y por lo tanto t6500 pensó incorrectamente que el proceso al que se hace referencia gc.pid(que en realidad no es un gcproceso real en este contexto, pero el shell actual) ya no existe

Arreglemos esto asegurándonos de que el PID de Windows esté escrito gc.piden este script de prueba para que git.exepueda comprender que ese proceso todavía existe.

Mi comprensión sobre las conexiones entre ellos es

• Cygwin ofrece la emulación POSIX sobre ventanas
• msys intentó simplificar Cygwin pero está obsoleto desde 2010
• msysGit : Git permitido hasta 1.9.4 en Windows (podría llamarse git-for-windows-1.X ), basado en una versión anterior de msys.
• msys2 : un Cygwin simplificado, bifurcado a partir de él, con cambios de msys y sincronizado con las características de Cygwin, integrado con Pacman
• MinGW - MinGW inicial, abandonado desde 2010
• MinGW-w64 : una integración más rápida y mejor con Windows, sin POSIX
• git-for-windows-2.x : ofrece Git desde 2.X para Windows usando MinGW-64 , MinGW-32 y cuando no es posible con un retroceso a msys2

Violín con definición gráfica completa en sirena .