Czy instalowanie Homebrew i Macports na tym samym komputerze jest bezpieczne?

Mam zainstalowane porty MacPort na moim komputerze iMac z zainstalowaną dużą liczbą portów.

Jestem jednak zainteresowany wypróbowaniem Homebrew, ponieważ słyszałem o nim wiele dobrych rzeczy i ponieważ zauważyłem, że zawiera on bardziej aktualne wersje kilku narzędzi, których używam.

Ale czy oba mogą współistnieć na tym samym komputerze, czy też muszę najpierw odinstalować MacPorts?

Ponadto, jeśli oba mogą być zainstalowane w tym samym czasie, czy będą one całkowicie od siebie niezależne? Jedną z funkcji Homebrew jest to, że nie instaluje ponownie nowych wersji rzeczy, które są już zawarte w systemie (np. Python). Czy obejmuje to również to, że nie instaluje wersji rzeczy, które są już obsługiwane przez MacPorts?

Co się stanie, jeśli następnie odinstaluję MacPorts?

Nie będą ze sobą dobrze współistnieć. Apple gcc szuka pewnych rzeczy w / usr / local. Oznacza to, że kompilacja Macports może znaleźć coś, czego porter się nie spodziewał. Zobacz listy mailowe i błędy Macports, aby znaleźć przykłady rzeczy znalezionych w / usr / local.

Udzieliłem innej odpowiedzi na podobne pytanie:

Homebrew spowoduje problemy podczas budowania oprogramowania ze źródła, jeśli jest ono zainstalowane w / usr / local. Jest to ustawienie domyślne, co jest złym wyborem, ponieważ ta ścieżka znajduje się w domyślnej ścieżce wyszukiwania kompilatorów i innych narzędzi. Dlatego kompilacje z innego oprogramowania do pakowania mogą wykryć niewłaściwą zależność, używając wersji Homebrew zamiast własnej.

Wiele lat temu, na samym początku projektu, nawet MacPorts używał / usr / local. Okazało się jednak, że nie współpracuje z innymi narzędziami, co jest udokumentowane w ich FAQ. Niestety programiści Homebrew nie chcieli słyszeć o wcześniejszych doświadczeniach i ignorowali takie fakty ...

Zasadniczo lepiej jest trzymać się tylko jednego narzędzia, aby uniknąć wszystkich problemów. MacPorts robi wszystko, co w ich mocy, aby załatać wszystkie ścieżki, które zostały zakodowane, np. Do / sw, którego używa Fink. Zwykle to działa, ale zainstalowanie czegokolwiek w / usr / local na pewno spowoduje problemy.

[…]

Kiedyś myślałem, że obawy o to, co zrobią narzędzia do budowania Gnu, /usr/localzbliżają się do paranoi. Narzędzia do kompilacji oczekują, że będzie tam wiele rzeczy: w dawnych dobrych czasach, zanim menedżerowie pakietów (żartuję), kompilowaliśmy wszystko /usr/local. Ale chociaż Autoconf zwykle rozwiązuje problemy, sama złożoność kompilacji wielu projektów typu open source powoduje problemy i problemy te mogą być trudne do wycofania się, gdy napotkasz trudności.

Ale ryzyko kłopotów z Autoconf znalezieniem czegoś, czego nie powinno być poniżej, /usr/localmusi być zrównoważone, ponieważ uciążliwość w utrzymaniu ma dwie, trzy lub cztery różne kopie Perla, Tcl i Ruby, każda z innym zasięgiem różnych bibliotek pakietów. Nieprzyjemny.

Ponieważ moje doświadczenie z MacPorts i Fink było zwykle rozdrażnieniem spowodowanym właśnie tym, i w pewnym momencie przeszedłem na kompilowanie staromodnego sposobu /usr/local, z przyjemnością zobaczyłem, że Homebrew nie zadzierało z tym. Próbowałem skonfigurować MacPorts do instalacji /usr/local, ale MacPorts robi wszystko, aby to utrudnić. Rozumiem, że motywacją jest ułatwienie sobie życia, gdy mamy do czynienia z wołaniem o pomoc na ich liście mailowej i śledzeniu błędów: pamiętaj jednak, że chociaż powinniśmy szanować wysiłek ochotników i traktować ich czas jako cenny, ich wygoda debugowania nie jest jedyną prostotą, która wpływa na ciebie jako użytkownika.

Homebrew, przynajmniej pod tym względem, robi rzeczy tak, jak kiedyś, a MacPorts stara się nie wtrącać. Jeśli chcesz udokumentować, które paczki potrzebujesz za pomocą Homebrew i wyczyścić / usr / local wyczyścić i ponownie zainstalować w przypadku trudności, zawsze możesz wycofać się na wypadek, gdyby coś poszło nie tak. A gdy zorientujesz się, że problemy w / usr / local nie wiążą się z ryzykiem trwałego uszkodzenia twoich maszyn, możesz poczuć się swobodniej.

Zwrócę tylko uwagę, o ile gorsze jest opakowanie na OSX niż FreeBSD: Apple tak naprawdę nie przejmuje się użytecznością swojego podsystemu BSD, ponieważ jest to problem, z którym mogliby pomóc.

Zgodnie z często zadawanymi pytaniami MacPorts :

Zauważ, że począwszy od 2.3.0 MacPorts może automatycznie ukryć / usr / local (i wszystkie inne pliki, od których port nie zależy) od systemów kompilacji portów. Ta funkcja nazywa się trybem śledzenia i jest aktywowana poprzez podanie flagi -t do portu, np

sudo port -t install <portname>

Jest to istotne, ponieważ zgodnie ze stroną instalacji Homebrew:

Jednym z powodów, dla których Homebrew działa w stosunku do konkurencji, jest to, że zalecamy instalację w / usr / local. Wybierz inny prefiks na własne ryzyko!

Dlatego też, przy niewielkim osobistym doświadczeniu, teoretyzuję, że zawsze użycie flagi -t dla instalacji MacPort powinno zapobiec większości problemów związanych z jednoczesnym istnieniem MacPorts i Homebrew w tym samym systemie. Aby odpowiedzieć na twoje ostatnie pytanie: Nie widzę żadnego powodu, dla którego odinstalowanie MacPorts spowodowałoby jakiekolwiek problemy.

Podczas instalowania homebrew na komputerze, na którym używam portów od lat, oto, co mogę przeczytać:

Warning: You have MacPorts or Fink installed:
  /opt/local/bin/port

This can cause trouble. You don't have to uninstall them, but you may want to
temporarily move them out of the way, e.g.

  sudo mv /opt/local ~/macports

Bądź ostrożny!

Rozwiązanie webappzero sudo port -t ...powinno pomóc. Szczerze mówiąc, biegam jednocześnie z Fink, MacPorts i Homebrew, z szacunkiem dla MacPorts (na razie zresztą), i używam tylko jednej z dwóch pozostałych rzeczy do zainstalowania rzeczy, których nie mogę uzyskać z MacPorts. W ten sposób napotkałem bardzo mało trudności, nawet zanim nauczyłem się tej port -tsztuczki. Jeśli jednak próbujesz używać wielu menedżerów pakietów do obsługi złożonych środowisk programistycznych i serwerowych, prawdopodobnie odczuwasz przynajmniej dyskomfort w świecie dyskomfortu. Wybierz jeden i unikaj innych, ale dla czegoś, czego desperacko potrzebujesz od nich, i postaw główny na wcześniejszej ścieżce.

Jeśli to, co słyszę, jest prawdą o tym, że Apple zabroni instalowania w / usr / innych niż własna firma Apple (a może już robią to w El Crapitan, do czego unikam oceniania aż do więcej problemy z tym rozwiązane), przypuszczam, że to złagodzi problem po tym, jak Homebrew domyślnie używa czegoś innego - niezależnie od tego, czy zgadzamy się z twardym podejściem Apple, czy nie.

W końcu podoba mi się pomysł ograniczenia własnych portów Apple'a do własnego drzewa, po prostu żałuję, że nie był to / usr /. Wolałbym, żeby użyli / System / bin / itd. Itp., Aby wyizolować swoje własne rzeczy, abym mógł łatwiej ominąć to za pomocą aktualnego oprogramowania zarządzanego przez społeczność.