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


162

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?

8
@JamesJohnston Antes de escribir esta pregunta, entendí (y es) que MSYS y MinGW se crearon como competidores de Cygwin porque Cygwin (al menos anteriormente; no estoy seguro de su estado actual) obligó a pasar a ningún código nuevo. una capa de compatibilidad bastante poco funcional en lugar de llamar directamente a las API de Windows. Como tal, siempre he visto a MSYS y sus familiares como un sistema de peso más ligero que Cygwin, por lo que no estaba interesado en el estado actual de Cygwin. Sin embargo, eso podría ser una buena pregunta de seguimiento, si está interesado; siéntase libre de preguntar si puede expresarlo sobre el tema.
jpmc26

44
Tenía esa impresión también hasta que empecé a cavar debajo de las sábanas ayer. Las tres versiones de MSYS que menciona son tenedores de Cygwin, como señala @Ray Donnelly. Entonces, en ese sentido, todos ellos son "Cygwin", y esta pregunta es realmente sobre Cygwin y sus tenedores. Como Ray señala, parece que MSYS está condenado. Examiné el código MSYS yo mismo; Es irremediablemente obsoleto y carece incluso de sincronización básica sobre la memoria compartida. Los mantenedores simplemente no se mantuvieron al día con el flujo ascendente, y nunca obtuvieron las soluciones para la memoria compartida que Cygwin obtuvo.
James Johnston

9
@JamesJohnston Creo que entendiste mal. Mi punto es que Cygwin no admite (¿no?) Construir nuevos binarios sin la capa de compatibilidad. MSYS y sus familiares lo hacen, a través de MinGW. Como tal, no estoy interesado en Cygwin, a pesar de ser muy consciente de que todos ellos tienen raíces en Cygwin. Como no estoy interesado en Cygwin, no tenía sentido preguntar al respecto. Esta pregunta también se centra principalmente en la historia de la bifurcación en sí y las razones para ello y algunas consecuencias rudimentarias de la misma. Al intentar elegir entre diferentes versiones de MSYS, la historia de Cygwin no es realmente relevante.
jpmc26

1
Lo que no entiendo es por qué los desarrolladores de MSYS2 y los desarrolladores de Cygwin no pueden aceptar los términos y dejar de pelear para que podamos dejar de tener estos tenedores estúpidos. Cygwin recibe poca atención como es, pero al menos hay empleados pagados de Red Hat trabajando en ello; los tenedores ni siquiera entienden eso. Encontré una discusión del año pasado en la lista de correo de Cygwin acerca de tener MSYS2 como un DLL de enlace para Cygwin para que MSYS2 no tuviera que bifurcar todo el DLL de Cygwin; aparentemente esas discusiones no fueron muy lejos. Si bien MSYS2 tiene energía ahora, preveo que se estanque como MSYS si / cuando los voluntarios de MSYS2 dejen de actualizarlo
James Johnston

1
@JamesJohnston Creo que podrías obtener mejores respuestas a tus preguntas en el canal IRC que Ray menciona en su respuesta. Esta cadena de comentarios se está haciendo bastante larga y se está desviando del tema.
jpmc26

Respuestas:


178

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.


66
¿Se puede usar msys2 para construir y ejecutar git (es decir, reemplazar msysgit)?
eckes

10
MSYS2 tiene un paquete git. Es una versión MSYS2 en lugar de una versión nativa. Para instalar git: pacman -S git .. también tenemos un puerto de trabajo en curso de msysgit en nuestro repositorio de paquetes MINGW.
Ray Donnelly

16
No, nuestro git MSYS2 tiene funciones completas y no está pirateado. Lo usamos ampliamente en el desarrollo de otros paquetes. Existe la preocupación de que MSYS2 (ya que es una bifurcación de Cygwin) agrega una gran cantidad de gastos generales a las operaciones de archivo y debido a que git es pesado en la operación de archivos, un git nativo sería más rápido. La forma de probar o refutar esto es tener ambos y compararlos, así que eso es lo que haremos. Debo tener cuidado con los términos aquí, ya que mis referencias a msysgit son a dos cosas diferentes, la bifurcación de msys con Windows nativo git y también Windows nativo git. Aquí me estoy refiriendo a este último!
Ray Donnelly

77
@eckes Solo quiero decir que he estado usando MSYS2 para git durante algunos meses. MSYS2 tiene un par de áreas difíciles (¿qué software no tiene?), Pero me ha encantado usarlo. Ninguno de ellos estaba relacionado con git en sí.
jpmc26

77
La promesa de msys2 está a la altura de mis expectativas. Sigan con el buen trabajo, @RayDonnelly
bvj

73

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:

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.


1
Esto plantea una pregunta muy interesante: 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? @RayDonnelly arriba menciona que el equipo de MSYS2 tenía interés en crear ese tipo de binarios para ver qué tipo de diferencia de rendimiento hace.
jpmc26

44
Aún no nos hemos fusionado por completo, no. Aunque estamos trabajando en eso.
Ray Donnelly

44
Para ampliar eso ... Todavía no, por ahora, el paquete git de MSYS2 todavía se vincula a msys-2.0.dll, hay un proceso continuo para fusionar MSYS2 con Git para Windows 'y una vez que esto se complete, esperamos simplemente soltar nuestro paquete git para su versión totalmente nativa ya que existen paquetes vinculados con msys-2.0.dll para admitir la creación de software nativo y no son un objetivo final por derecho propio.
Ray Donnelly

1
@RayDonnelly ¿Cuál es el estado en este momento? Si reemplaza Git para Windows con MSYS2 (gestión de paquetes), ¿hay alguna desventaja?
Brecht Machiels


18

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

Compare Cygwin, msys, msys2, MinGW, git-for-windows, msysGit

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


1
Buenos gráficos. +1. Sin embargo, el "Git para Windows 1.0" se realizó realmente con el mejor esfuerzo: stackoverflow.com/a/1704687/6309 (que menciono en stackoverflow.com/a/50555740/6309 )
VonC
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.