locations lav error msys msys2

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



git ab (2)

He estado buscando, pero no puedo encontrar una descripción detallada de lo que está pasando con estas 3 versiones de MSYS. (Es muy posible que no sepa qué buscar). Entiendo que MSYS sea un puerto mínimo de herramientas de Linux para apoyar el desarrollo usando MinGW, pero no tengo claro cuál es la relación entre los tres o el equipos que los desarrollaron / mantuvieron.

Cuestiones particulares a tratar:

  • ¿Cuáles están en desarrollo activo? (En particular, ¿MSYS está muerto y MSYS2 está activo?)
  • ¿Cuál es la relación entre los grupos que los mantienen? (En particular, ¿el equipo de MSYS creó MSYS2?)
  • ¿Msysgit simplemente usa uno de los otros, o tienen su propia rama de MSYS?
  • ¿Alguno de estos es compatible entre ellos?
  • ¿Hay algún problema de compatibilidad con versiones particulares de Windows para cualquiera de estos?
  • ¿Uno proporciona características importantes 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 se mantuvo con Cygwin.

msysgit es una bifurcación de una versión ligeramente anterior 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 reciente bifurcación de Cygwin que rastrea la última versión de Cygwin para que no termine desactualizada. Alexey reenvió los viejos parches MSYS y agregó algunos propios.

Además de proporcionar las herramientas necesarias de Unix para compilar software nativo, el objetivo declarado de MSYS, transferimos 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 parches) para la creación de software. En mi humilde opinión, la adopción de Pacman cambia significativamente las cosas para el desarrollo de código abierto en Windows. En lugar de que todos pirateen sus propios scripts de shell para crear software de una manera incompatible, los paquetes ahora pueden depender de otros paquetes y los archivos PKGBUILD y los parches asociados se pueden usar como referencia para construir nuevos PKGBUILD. Es lo más parecido a un sistema Linux como Windows (nativo) que Windows puede obtener (Arch en particular) y permite la actualización simple de todos los paquetes instalados.

Nuestro objetivo es Windows XP SP3 como mínimo y admitimos tanto Windows de 32 bits como 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 incorporar nuestros parches a los proyectos que creamos y solicitar 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 amigable para el usuario 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 un compromiso muy detallado que explica la importancia de msys2 para el nuevo git-for-windows que reemplazó a msysgit a principios de 2015 .

Ver commit df5218b (13 Jan 2016) por Johannes Schindelin ( dscho ) .
(Fusionada por Junio ​​C Hamano - gitster - in 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 for Windows querían que ese gran salto coincidiera con un muy necesario salto de MSys a MSys2.

Para entender por qué este es un tema tan importante, se debe tener 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 estará disponible .

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

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

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

Los ejecutables de Git for Windows se crean con este último y, por lo tanto, son solo programas Win32. Para discernir los ejecutables que requieren la capa de emulación POSIX de los que no, estos últimos se llaman MinGW (GNU mínimo para Windows) cuando los primeros se llaman ejecutables MSys .

Sin embargo, esta confianza en MSys también generó desafíos:

  • algunos de nuestros cambios en el tiempo de ejecución de MSys -necesario para admitir mejor a Git para Windows- no se aceptaron en la fase inicial, por lo que tuvimos que mantener nuestro propio fork.
  • Además, el tiempo de ejecución de MSys no se desarrolló aún más para admitir UTF-8 o 64 bits, y además de carecer de un sistema de gestión de paquetes hasta mucho más tarde (cuando se introdujo mingw-get ), muchos paquetes proporcionados por el retraso del proyecto MSys / MinGW detrás de las respectivas versiones del código fuente, en particular Bash y OpenSSL.

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

Afortunadamente, 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 actualizado con el código fuente de Cygwin .
De este modo, ya admite Unicode internamente, y también ofrece la compatibilidad de 64 bits que ansiamos desde el comienzo del proyecto Git for Windows.

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

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

Todavía requería un esfuerzo de dos meses para llevar todo a un estado en el que pasara el conjunto de pruebas de Git, muchos meses más hasta que se lanzara el primer Git oficial para Windows 2.x y un par de parches aún esperan su envío a los respectivos proyectos previos . Sin embargo, sin MSys2, la modernización de Git para Windows simplemente no habría sucedido .

Este compromiso establece el trabajo básico para respaldar las compilaciones de Git basadas en MSys2.