Je veux compiler de nouvelles versions d'openssl, de bash et d'autres outils Unix similaires. de la même façon qu'Apple le ferait. Je veux créer des liens avec les bibliothèques intégrées au système d'exploitation lorsque cela est possible, et je veux copier les binaires qui en résultent dans le répertoire /usr/bin qui remplace ce qu'Apple livre avec OS X.
Je suis conscient que c'est généralement un très mauvaise idée pour deux raisons :
- Une mise à jour d'OS X pourrait réintégrer les binaires d'Apple, annulant votre travail et laissant votre système dans un état inconnu.
- Certains logiciels peuvent dépendre du comportement spécifique des binaires d'Apple.
Au lieu de cela, il est généralement recommandé aux utilisateurs de mac d'installer des binaires personnalisés à côté des binaires système d'Apple. Homebrew et MacPorts fonctionnent tous deux selon ce principe.
Cependant, j'utilise Mavericks, qui ne recevra jamais une autre mise à jour logicielle d'Apple. Les binaires Apple sur mon système présentent des failles de sécurité connues, ce qui, selon l'OMI, l'emporte sur les problèmes de compatibilité théoriques.
Existe-t-il une manière standard de procéder, ou est-ce que ce serait différent pour chaque programme ? Puis-je d'une manière ou d'une autre tirer parti de certaines parties du projet MacPorts, par exemple, pour faciliter le processus, ou dois-je installer toutes les dépendances de compilation à partir de zéro ?
Si cela n'est tout simplement pas réalisable, j'aimerais le savoir aussi.
0 votes
Je commencerais par mettre à niveau
bashpuis installer GNU Core Utilities et ensuiteopenssletc. Personnellement, je préfère compiler directement à partir de code source mais utiliseraitbrewsi nécessaire.0 votes
Je vous comprends... Je me débats avec les mêmes questions sur un ancien et un nouveau Macbook Pro. Mais il y a de l'espoir dans le fait que @ThorbjørnRavnAndersen nous informe que c'est... " trivialement simple à faire " dans l'un de ses commentaires perspicaces. :P
1 votes
@Seamus Je viens de lire le fil de discussion - je pense que vous venez de deux points de vue opposés, donc quelque chose qui semble "trivial" pour lui peut sembler très différent pour vous, et vice versa. D'après ce que j'ai lu, il semble que vous soyez habitué à la façon dont les versions de logiciels fonctionnent, par exemple sous Windows. Ici, nous avons l'habitude de passer à de nouvelles versions numérotées (par exemple, la version 5 est meilleure que la 4 est meilleure que la 3, etc.) Ainsi, lorsque quelque chose se produit, comme un problème de sécurité, vous passez de la version 4 à la version 5. Cependant, ce n'est pas de cette manière que les versions fonctionnent habituellement sur les systèmes Unix - donc si [...]
1 votes
[...] s'il vient d'un environnement Unix ou serveur, cette vision du monde lui semblera très étrangère. Au contraire, sur les systèmes Unixoïdes, vous êtes habitué à voir la version 3, la version 4 et la version 5 comme étant essentiellement des programmes différents offrant des fonctionnalités différentes. Ici, il est d'usage de ne PAS faire de mise à jour de la version 4 à la version 5 lorsque quelque chose comme un problème de sécurité survient. Au lieu de cela, une nouvelle version de la version 4 est créée et inclut un petit changement qui résout le problème en question. Cela signifie que les manuels, l'expérience utilisateur, les intégrations existantes, etc. continuent de fonctionner comme avant - il s'agit essentiellement d'une [...].
1 votes
[...] changement non rompu. Vous n'obtenez pas de nouvelles fonctionnalités, mais vous obtenez une nouvelle version du logiciel. Ainsi, par exemple, la version de bash incluse dans MacOS peut toujours indiquer 3.2, mais ce n'est certainement pas la même version 3.2 qui se trouve dans la dernière version de Catalina, comme c'est le cas dans Mavericks par exemple. Les deux programmes sont différents dans la mesure où la version Catalina est une version 2020 de bash 3.2 qui contient divers changements et corrections qui ne sont pas dans la version 2016 (ou plus ancienne) de Mavericks. Si vous êtes principalement soucieux de maintenir la compatibilité et de "ne pas faire de vagues", c'est la manière optimale.
1 votes
Bien sûr, si vous recherchez de nouvelles fonctionnalités, vous serez cruellement déçu par cette méthode. Dans ce cas, vous feriez mieux d'installer bash 5 (par exemple) dans /usr/local/bin, afin de pouvoir l'utiliser vous-même pour vos propres usages, tout en conservant la version 3.2 pour les scripts fournis par le système, etc.
0 votes
@jksoegaard : J'apprécie tout cela. Je devrais probablement être gêné de l'admettre, mais j'ai utilisé des systèmes Unix pendant des années, et je ne savais pas que les anciennes versions (en particulier celles datant de 14 ans) étaient maintenues. Même les mises à jour d'Apple incluent généralement des termes comme "résolution de problèmes de sécurité".
1 votes
@Seamus Bien sûr, presque tous les types de systèmes Unix existants maintiennent les "anciennes" versions. Pour prendre un exemple aléatoire de logiciel que beaucoup connaissent. PHP est un langage de programmation web bien connu qui avait une série 5.6 très populaire, qui a cessé d'être supportée par le fournisseur en 2018. À ce moment-là, ils le prenaient en charge depuis 4 ans, il s'agissait donc vraiment d'une "ancienne version" à ce moment-là. Cependant, Debian inclut toujours PHP 5.6 dans certaines de ses versions encore prises en charge - ils créent donc eux-mêmes de nouvelles versions de PHP 5.6 pour corriger divers problèmes - en fait [...]
0 votes
[...] La dernière mise à jour de PHP 5.6 est sortie il y a tout juste deux mois.
0 votes
Je viens de vérifier Ubuntu Linux - ils supportent toujours PHP 5.5 par exemple. Cette version a cessé d'être prise en charge par le fournisseur à la mi-2016. Il est difficile de rechercher un "vieux logiciel", mais je viens de remarquer que la même Ubuntu a CakePHP 1.3 par exemple. Il s'agit d'un logiciel datant de 2012.
0 votes
@jksoegaard : C'est intéressant. Je sais que l'OP et moi souhaitons tous deux qu'Apple maintienne les anciennes versions de MacOS. :0
0 votes
Ils prennent en charge les anciennes versions de MacOS, mais peut-être pas aussi loin que vous le souhaiteriez. Ils semblent généralement prendre en charge la version actuelle ainsi que les deux versions précédentes. Par exemple, nous sommes aujourd'hui en 10.15, mais ils ont publié une mise à jour pour la 10.13 il y a quelques semaines. En général, je vous déconseille fortement d'utiliser Mavericks, sauf si vous avez une raison impérieuse de vous y tenir - et même dans ce cas, je préférerais qu'il soit airgapped.