Comment msys, msys2 et msysgit sont-ils liés?

Question

J'ai fait des recherches, mais je ne trouve pas de description détaillée de ce qui se passe avec ces 3 versions de MSYS. (Il est tout à fait possible que je ne sache pas quoi chercher.) Je comprends que MSYS est un portage minimal des outils Linux permettant de prendre en charge le développement à l'aide de MinGW, mais je ne suis pas clair sur la relation entre eux les équipes qui les ont développés/entretenus.

Problèmes particuliers à traiter:

• Lesquels sont en développement actif? (En particulier, MSYS est-il mort et MSYS2 est-il actif?)
• Quelle est la relation entre les groupes qui les maintiennent? (En particulier, l'équipe MSYS a-t-elle créé MSYS2?)
• Msysgit utilise-t-il simplement l’un des autres ou at-il sa propre branche de MSYS?
• Est-ce que certains d'entre eux sont compatibles les uns avec les autres?
• Existe-t-il des problèmes de compatibilité avec certaines versions de Windows?
• Est-ce que l'un fournit des fonctionnalités majeures par rapport à l'autre?

Answer 1

Disclaimer: Je suis un développeur MSYS2

Bien que MSYS ne soit pas mort, je dirais qu'il n'a pas l'air très sain non plus. C'est un projet initié par l'équipe mingw il y a de nombreuses années en tant que une fourche de Cygwin qui n'a jamais suivi le rythme de Cygwin.

msysgit est une branche d'une version légèrement plus ancienne de MSYS avec certains correctifs personnalisés, d'anciennes versions de bash et de Perl et un port natif de git.

MSYS2 est un projet lancé par Alexey Pavlov de l'équipe mingw-builds (qui sont les emballeurs officiels pour les chaînes d'outils MinGW-w64) en tant que un fork récent de Cygwin qui suit de près le dernier Cygwin afin qu’il ne soit pas obsolète. Alexey forward a porté les anciens correctifs MSYS et en a ajouté certains.

En plus de fournir les outils Unix nécessaires à la compilation de logiciels natifs - objectif déclaré de MSYS -, nous avons également porté le gestionnaire de paquets Pacman d'Arch Linux. Pacman ne se limite pas à la gestion de paquets binaires (même s’il le fait très bien). Il dispose d'une infrastructure de création de logiciels appelée makepkg qui permet la création de recettes (PKGBUILD et fichiers de correctifs) pour la création de logiciels. IMHO l'adoption de Pacman change considérablement les choses pour le développement Open Source sous Windows. Au lieu de piratage sur des scripts Shell sur mesure pour créer des logiciels incompatibles, les packages peuvent désormais dépendre d'autres packages et les fichiers PKGBUILD et les correctifs associés peuvent être utilisés comme référence pour la construction de nouveaux PKGBUILD. C'est aussi proche d'un système Linux qu'un Windows (natif) peut obtenir (Arch en particulier) et permet une mise à jour simple de tous les packages installés.

Nous ciblons Windows XP SP3 au minimum et prenons en charge les systèmes Windows 32 bits et 64 bits. Nous vous demandons de ne jamais mélanger MSYS2 avec msys ou msysgit. Pacman est utilisé pour gérer l'ensemble du système et, en tant que tel, les fichiers des autres systèmes provoqueront des conflits.

Nous essayons également d’améliorer nos correctifs avec les projets que nous construisons et sollicitons activement les contributions d’autres projets Open Source. Nous espérons que les autres trouveront facile de travailler avec nous.

Notre site Web principal est sur Sourceforge et contient des liens vers nos référentiels PKGBUILD. Nous avons également un site d'installation plus convivial sur github .

N'hésitez pas à nous rejoindre sur IRC (oftc # msys2) si vous souhaitez plus d'informations.

Answer 2

Git 2.8 (mars 2016) inclut un commit très détaillé qui explique l'importance de msys2 pour le nouveau git-for-windows qui a remplacé msysgit au début de 2015 .

Voir commit df5218b (13 janvier 2016) par Johannes Schindelin (dscho) .
^{(Fusionné par Junio ​​C Hamano - gitster - dans commit 116a866 , 29 janv. 2016)}

Pendant longtemps, Git pour Windows a pris du retard par rapport aux versions 2.x de Git car les développeurs de Git pour Windows voulaient que ce grand saut coïncide avec un passage bien mérité du passage de MSys à MSys2.

Pour comprendre pourquoi c’est un si gros problème, , il faut noter que de nombreuses parties de Git ne sont pas écrites en C portable, mais que Git s’appuie sur un shell POSIX et sur Perl pour être disponibles .

Pour prendre en charge les scripts, Git for Windows doit fournir une couche d'émulation POSIX minimale avec Bash et Perl intégrés , et lorsque l'effort de Git pour Windows a démarré dans En août 2007, ce développeur a choisi d'utiliser MSys, une version simplifiée de Cygwin .
Par conséquent, le nom original du projet était "msysGit" (ce qui, malheureusement, a provoqué une confusion = beaucoup car peu d'utilisateurs de Windows connaissent MSys et encore moins d'attention).

Pour compiler le code C de Git pour Windows, MSys a également été utilisé: il contient deux versions du compilateur GNU C Compiler:

• celui qui lie implicitement à la couche d'émulation POSIX,
• et un autre qui cible l'API Win32 standard (avec quelques fonctions pratiques ajoutées).

Les exécutables de Git for Windows sont construits à l'aide de ces derniers et ne sont donc que des programmes Win32. Pour distinguer les exécutables nécessitant la couche d'émulation POSIX de ceux qui n'en ont pas, ceux-ci sont appelés MinGW (Minimal GNU pour Windows) lorsque les premiers sont appelés MSys exécutables .

Cette utilisation de MSys a également posé des problèmes:

• certaines des modifications apportées à l'exécution de MSys - nécessaires pour mieux prendre en charge Git for Windows - n'ont pas été acceptées en amont; nous avons donc dû gérer notre propre fork.
• En outre, l’exécution de MSys n’a pas été développée davantage pour prendre en charge, par exemple, UTF-8 ou 64 bits, et mis à part l'absence d'un système de gestion des paquets beaucoup plus tard (lorsque mingw-get A été introduit), de nombreux paquets fournis par le projet MSys/MinGW sont en retard sur les versions respectives du code source, en particulier Bash et OpenSSL.

Pendant un certain temps, le projet Git for Windows a tenté de remédier à la situation en essayant de créer de nouvelles versions de ces packages, mais la situation est rapidement devenue intenable, notamment avec des problèmes tels que le bogue Heartbleed nécessitant Swift action cela n'a rien à voir avec le développement ultérieur de Git pour Windows.

Heureusement, entre temps, le projet MSys2 ( https://msys2.github.io/ ) est apparu et a été choisi pour constituer la base de Git for Windows 2.x.
Tout comme MSys, MSys2 est une version allégée de Cygwin, mais il est activement mis à jour avec le code source de Cygwin . .
Ainsi, il prend déjà en charge Unicode en interne et offre également la prise en charge 64 bits que nous attendions depuis le début du projet Git for Windows.

MSys2 a également porté le système de gestion de paquets Pacman à partir d’Arch Linux et l’utilise beaucoup . Cela apporte le même confort auquel les utilisateurs Linux sont habitués depuis yum ou apt-get, Et auquel les utilisateurs MacOSX sont habitués depuis Homebrew ou MacPorts, ou les utilisateurs BSD du système Ports, à MSys2. : un simple pacman -Syu mettra à jour tous les packages installés avec les dernières versions disponibles.

MSys2 est également very actif, fournissant généralement les mises à jour de paquetages plusieurs fois par semaine.

Il fallait encore deux mois d'effort pour que tout aboutisse à la réussite de la suite de tests de Git, plusieurs mois avant la sortie du premier logiciel officiel Git pour Windows 2.x, et quelques correctifs attendent toujours leur soumission aux projets en amont respectifs. . Pourtant, sans MSys2, la modernisation de Git pour Windows n'aurait tout simplement pas eu lieu .

Ce commit pose les bases de la prise en charge des générations Git basées sur MSys2.

---

Dans les commentaires , la question avait été posée en janvier 2016:

Puisque Git pour Windows est déjà basé sur MSYS2, les fichiers binaires qui ne dépendent pas de la couche d’émulation sont-ils disponibles sous forme de package MSYS2?

Ray Donnelly a répondu à l'époque:

Nous n'avons pas encore complètement fusionné, non. Nous y travaillons cependant.

Mais ... madzfait remarquer qu'au début de 2017, cet effort n'a pas abouti.
Voir:

• Alexpux/MSYS2-packages PR 786
• git-for-windows/git Numéro 284

Le problème est que je ne peux pas contribuer aux changements qui aboutiraient à un nouveau runtime de msys2 en temps voulu.
Ce n’est pas un gros problème, cependant: je vais simplement laisser la fourche de Git pour Windows fonctionner indéfiniment.

Le wiki mentionne donc maintenant (2018):

Git pour Windows a créé des correctifs pour msys2-runtime qui n'ont pas été envoyés en amont. (Cela avait été prévu, mais il a été déterminé dans le numéro 284 que cela ne se produirait probablement pas.)
Cela signifie que vous devez installer msys2-runtime personnalisé pour Git for Windows afin d’avoir un git pleinement fonctionnel dans MSYS2.

---

Notez que, depuis commit aeb582a9 (Git 2.22, T2 2019), le projet Git pour Windows a démarré le processus de mise à niveau vers une version d'exécution MSYS2 basée sur Cygwin v3.x.

mingw: autorise la construction avec un environnement d'exécution MSYS2 v3.x

Récemment, le projet Git pour Windows a démarré le processus de mise à niveau vers une version d'exécution MSYS2 basée sur Cygwin v3.x.

Cela a pour conséquence très notable que $(uname -r) ne rapporte plus une version commençant par "2", mais une version avec "3".

Cela rompt notre construction, car df5218b (config.mak.uname: Support MSys2, 2016-01-13, Git v2.8.0-rc0) ne s'attendait tout simplement pas à la version rapportée par uname -r dépend de la version de Cygwin sous-jacente: la version rapportée devait correspondre au "2" dans "MSYS2".

Donc, inversons ce scénario de test pour tester toute autre chose qu'une version commençant par "1" (pour MSys).
Cela devrait nous protéger pour l'avenir, même si Cygwin publie des versions telles que 314.272.65536.

---

Git 2.22 (T2 2019) assurera la pérennité d'un test par rapport à une mise à jour de la série MSYS2 runtime v3.x.

Voir commit c871fbe (07 mai 2019) par Johannes Schindelin (dscho) .
^{(Fusionné par Junio ​​C Hamano - gitster - dans commit b20b8fe , 19 mai 2019)}

t6500(mingw): utilise le PID Windows du shell

Dans Git pour Windows, nous utilisons MSYS2 Bash, qui hérite d’un modèle PID non standard de la couche d’émulation POSIX de Cygwin: chaque processus MSYS2 possède un PID Windows standard et un PID MSYS2 (qui correspond à un processus d’ombre qui émule). Traitement du signal de type Unix).

Avec la mise à niveau vers la version v3.x de MSYS2, ce processus instantané n’est plus accessible via OpenProcess(), et le t6500 pensait donc à tort que le processus référencé dans gc.pid (Qui le processus réel gc dans ce contexte, mais le shell actuel) n’existe plus.

Corrigeons cela en vérifiant que le PID Windows est écrit dans gc.pid Dans ce script de test afin que git.exe Puisse comprendre que ce processus existe toujours.

Answer 3

Ma compréhension des liens entre eux est

• cygwin offre l’émulation POSIX au-dessus de Windows
• msys a essayé de simplifier cygwin mais est obsolète à partir de 2010
• msysGit - autorisait le git jusqu'à 1.9.4 dans les fenêtres (pourrait être appelé git-for-windows-1. X ), basé sur une ancienne version de msys.
• msys2 - un cygwin simplifié, dérivé de celui-ci, contenant les modifications apportées par msys et synchronisé avec les fonctions de cygwin, intégré à pacman
• minGW - minGW initiale, abandonnée à partir de 2010
• minGW-w64 - une intégration plus rapide et meilleure avec Windows, sans POSIX
• git-for-windows-2.x - offre git à partir de 2.X pour Windows avec minGW-64 , minGW-32 et quand ce n'est pas possible avec un repli sur msys2

Violon avec définition complète du graphique dans sirène