Pytanie:
Instalowanie rzeczy: brew a oficjalny instalator - którego należy użyć?
winklerrr
2020-08-31 18:10:02 UTC
view on stackexchange narkive permalink

Zastanawiam się, jak należy instalować programy na komputerze Mac? Przez Homebrew lub oficjalny instalator, jeśli taki istnieje?

Powiedzmy, że chcę zainstalować Node.js na moim Macu. oficjalny przewodnik instalacji macOS oferuje różne alternatywy. Najpierw zainstalowałem go za pośrednictwem oficjalnego pliku instalatora. Następnie przełączyłem się na Homebrew i zainstalowałem go przez brew install node .

Więc teraz wygląda na to, że mam dwie instalacje Node w moim systemie. Kiedy uruchamiam polecenie który węzeł , wyświetla / usr / local / bin . Więc oczywiście oficjalna instalacja jest tutaj korzystna (może dlatego, że zainstalowałem ją jako pierwszą? Nie wiem). Instalacja węzła z Homebrew znajduje się w / usr / local / Cellar .

Moje pytania są następujące:

  1. Czy powinienem używać Homebrew czy oficjalnego instalatora? Czemu? Wydaje mi się, że Homebrew ma pewne zalety w stosunku do instalatora, takie jak łatwiejszy proces odinstalowywania i lepsza możliwość aktualizacji zainstalowanych pakietów oprogramowania.
  2. Jak mogę przełączyć system z instalacji / usr / local / bin węzła na / usr / local / Cellar ?
Wydaje mi się, że "oficjalna" wersja została zainstalowana w `/ usr / bin /`, ponieważ można tam instalować tylko programy zatwierdzone przez Apple.Gdybym był tobą, otworzyłbym Findera i spojrzał na folder `/ usr / local / bin /`.Może się okazać, że `/ usr / local / bin / node` jest dowiązaniem symbolicznym do` / usr / local / Cellar / node`
wykonaj także `node --version` i` / usr / local / Cellar / node / node --version` (dopasowując drugą wersję do tego, co jest na twoim komputerze) i porównując dwa numery wersji.Zwykle będziesz potrzebować wersji z wyższym numerem wersji
Nawet z instalatorem Node.js zwykle nie instalujesz w / usr / bin (w najnowszych wersjach macOS prawdopodobnie i tak nie możesz).Homebrew zwykle łączy się z / usr / local / bin, więc możesz chcieć sprawdzić, czy plik jest tylko dowiązaniem symbolicznym do piwnicy.
Siedem odpowiedzi:
Allan
2020-08-31 18:54:11 UTC
view on stackexchange narkive permalink

Podobne pytanie jest tutaj w Ask Different - Jakie są zalety i wady MacPorts, Fink i Homebrew? - w którym porównuje się różne menedżery pakietów. To doskonała lektura i zachęcam do jej przejrzenia.

Czy powinienem używać Homebrew czy oficjalnego instalatora? Dlaczego?

Główną różnicą między używaniem Homebrew a używaniem pakietu instalacyjnego są zależności czasu kompilacji. Homebrew (i MacPorts) świetnie sobie z tym radzą. Jednak w przypadku pakietu nie ma wymagań dotyczących kompilacji, a oprogramowanie jest gotowe do pracy.

Odinstalowanie nie stanowi już problemu. Homebrew będzie zarządzać procesem dezinstalacji i obsłużyć zależności czasu wykonywania, przycinając je w razie potrzeby. Jednak w przypadku bezpłatnych aplikacji, takich jak AppCleaner, całkowite usunięcie aplikacji nie stanowi problemu.

Podsumowując, wszystko sprowadza się do Twojego przepływu pracy. Jeśli potrzebujesz tylko narzędzia, pobierz pakiet. Jeśli korzystasz z więcej niż jednej i istnieją biblioteki współdzielone, którymi chcesz zarządzać, przejdź do Homebrew.

Jak mogę przełączyć system z instalacji / usr / local / bin Node na / usr / local / Cellar?

Zmieniasz swoją ścieżkę

W zależności od używanej powłoki ( ~ / .bash_profile dla Bash i ~ / .zprofile dla Zsh) wystarczy dodać katalog nowego narzędzia (patrz ZSH : .zprofile, .zshrc, .zlogin - co gdzie jest?, aby uzyskać więcej informacji). Aby upewnić się, że zostanie wybrana przed inną (natywną) aplikacją, należy umieścić ją jako pierwszą w zmiennej ścieżki. Na przykład domyślna ścieżka to (ustawiona przez path_helper )

  / usr / local / bin: / usr / bin: / bin: / usr / sbin: / sbin
 

W swoim profilu po prostu dodaj wiersz wskazujący, gdzie znajdują się pliki binarne. Na swoim przykładzie dodaj swoją ścieżkę:

  PATH = / usr / local / Cellar: $ PATH
 

Twoja nowa ścieżka będzie miała katalog Cellar dołączony do istniejącego.Ponieważ jest poprzedzona (znajduje się przed) twoją istniejącą ścieżką, będzie najpierw szukać w tym katalogu.Zobacz Dokumentację Homebrew, aby uzyskać szczegółowe informacje.Osobiście używam kombinacji MacPorts i „oficjalnych” instalatorów, więc używam innej struktury katalogów.YMMV.

`PATH = / usr / local / Cellar: $ PATH` powinno mieć wartość` PATH = / usr / local / Cellar / package / version / bin: $ PATH`.W rzeczywistości powinno to być po prostu `PATH = / usr / local / bin: $ PATH`, który zawiera dowiązania symboliczne brew installs.
@anki Moim celem jest * nauczenie * OP, jak modyfikować rzeczy, aby dopasować je do ich potrzeb, a nie udzielenie odpowiedzi na pytanie, gdzie Homebrew domyślnie wybiera swoją ścieżkę.Końcowym rezultatem jest określenie, co działa najlepiej, a nie Homebew HOWTO
@Allan byłby to dobry cel, ale musielibyśmy również nauczyć OP, że wyszukiwania w `PATH` nie są rekurencyjne, a pliki binarne nie są bezpośrednio w` / usr / local / Cellar`.Więc nawet jeśli istnieje katalog `node` w` / usr / local / Cellar` w `$ PATH`, polecenie` node` jest ukryte w `/ usr / local / Cellar / node / / bin`nie zostanie znaleziony.
Skąd fiksacja na tej konkretnej ścieżce?Dosłownie powiedziałem * używając twojego przykładu *, ponieważ było to pytanie tak, jak zostało napisane.Zbyt długo o tym myślisz, ponieważ nigdzie nie powiedziałem, że przeszukiwanie ścieżki jest rekurencyjne.W rzeczywistości powiedziałem, aby „użyć ścieżki, w której znajdują się Twoje pliki binarne i połączonej z dokumentacją Homebrew.Ponownie odpowiadam na zadane pytanie i nie piszę Homebrew HOWTO
anki
2020-08-31 18:38:57 UTC
view on stackexchange narkive permalink

Czy powinienem używać Homebrew czy oficjalnego instalatora? Dlaczego?

Zawsze wolę menedżera pakietów, takiego jak brew lub conda, zamiast plików .pkg, które nie zapewniają dezinstalatorów.

  • Można sprawdzić, jakie zależności zostaną zainstalowane.
  • Łatwe czyszczenie.
  • Nie musisz pamiętać, czy coś zostało dostarczone wraz ze standardową instalacją macOS, czy zostało zainstalowane później.
  • Nie musisz wpisywać hasła roota.

Narzędzia, których nie ma w brew i które sam buduję, są zbudowane za pomocą CMAKE_INSTALL_PREFIX i zainstalowane w ~ / Applications . Pliki binarne, które pobieram bezpośrednio skądś, są również przechowywane w ~/Applications

Następnie dodaję ścieżkę instalacyjną do PATH przez ~ / .bash_profile .


brew przechowuje rzeczywiste pliki binarne lub biblioteki w / usr / local / Cellar / <package> / <version> / bin i tworzy alias w / usr / local / bin lub / usr / local / lib lub include. I umieszcza ścieżkę / usr / local / bin w zmiennej PATH .

Więc oczywiście oficjalna instalacja jest tutaj korzystna (może dlatego, że zainstalowałem ją najpierw? Nie wiem)

Nie, to pierwszeństwo. W zmiennej PATH / usr / local / bin jest domyślnie wymieniony przed / usr / bin . (Zobacz plik install.sh). Więc kiedy zostanie znaleziony plik binarny, nadchodzące lokalizacje nie są sprawdzane.


Co pobrałeś z witryny jest uproszczony

  curl "https://nodejs.org/dist/latest/node-${VERSION:-$(wget -qO- https://nodejs.org/dist/latest/ | sed -nE ' s |. * >node - (. *) \. pkg< / a>. * | \ 1 | p ')}. pkg "\
> "$ HOME / Downloads / node-latest.pkg" \
&& sudo installer -store -pkg "$ HOME / Downloads / node-latest.pkg" -target "/"
 

Domyślam się, że node jest zainstalowany w / usr / bin .


Więc żeby wszystko uporządkować,

  • Uruchom węzeł dezinstalacji brew
  • Pobierz plik xz z https://nodejs.org/dist/latest/ i sprawdź jego zawartość.
  • Po kolei znajdź wszystkie foldery i pliki, takie jak README i dziennik zmian, które pasują do pobranego xz, i usuń je.Najprawdopodobniej można je znaleźć w / usr / bin , / usr / local / bin .Pomogłoby tutaj użycie wyszukiwarki i sortowanie według „daty dodania”.
  • brew install node .

Jak mogę przełączyć system z instalacji / usr / local / bin Node na / usr / local / Cellar?

Po wykonaniu powyższych kroków i poprawnej instalacji brew, tj. echo $ PATH zawiera / usr / local / bin , nie maszzrobić coś dodatkowego.

Jak duży ślad ma HomeBrew?
~ 350 MB na repozytorium git i trochę pamięci podręcznej pobranych plików binarnych.Instalacje i tak przyjmują rozmiar, który by przyjęły, więc nie ma to znaczenia.
benwiggy
2020-08-31 19:24:31 UTC
view on stackexchange narkive permalink

Jeśli planujesz zainstalować dużo rzeczy, bardziej przydatny może być menedżer pakietów;jeśli jest tylko kilka rzeczy, które musisz zainstalować, które mają własne instalatory i których aktualizacja jest łatwa, instalacja czegoś takiego jak HomeBrew może po prostu dodać kolejną warstwę złożoności.

Umieszczenie wszystkich jajek w jednym koszyku ma również wpływ na bezpieczeństwo. https://medium.com/@vesirin/how-i-gained-commit-access-to-homebrew-in-30-minutes-2ae314df03ab

Saaru Lindestøkke
2020-09-01 02:38:22 UTC
view on stackexchange narkive permalink

Odnośnie twojego pierwszego pytania Czy powinienem używać Homebrew czy oficjalnego instalatora? Czuję potrzebę dodania wady korzystania z Homebrew, której nie widziałem tutaj lub w innym pytaniu: długoterminowa kompatybilność.

Weźmy na przykład El Capitan, który jest instalowany na komputerach Mac, których nie można dalej aktualizować.Chociaż te komputery Mac nadal mogą działać dobrze, Homebrew (jako Apple) porzucił wsparcie dla tej wersji systemu operacyjnego. Teraz, jeśli spróbujesz zaparzyć coś na El Capitan, może to zadziałać, może się nie powieść lub może rozpocząć długą procedurę kompilacji i wtedy się nie powiedzie.

Stwierdziłem, że nie warto wypróbowywać tego procesu za każdym razem, więc teraz na starym komputerze instaluję wszystko za pomocą oficjalnego instalatora.

Dlaczego nie możesz zainstalować określonych wersji formuł?Zobacz: https://stackoverflow.com/questions/3987683/homebrew-install-specific-version-of-formula
@Allan To nie pozwoli na zainstalowanie nowych wersji odpowiedniego pliku binarnego
Rozumiem, że @nohillside, Spodziewałbym się, że zostanie zainstalowana najnowsza kompatybilna wersja, określając ją.
@Allan Spróbuję tego, ale potem zaczyna się poszukiwanie ostatniej wersji na homebrew, która była kompatybilna z El Capitan.Przypominam sobie też coś o butelkach El Capitan (to są skompilowana formuła naparu, prawda?) Powoli znikają z serwerów homebrew.
Nie mogę mówić o tym, co dzieje się na serwerach Homebrew poza faktem, że używam MacPorts (głównie dlatego, że jest oparty na modelu portów BSD; patrz [FreshPorts] (https://freshports.org)).Udało mi się jednak znaleźć starsze wersje prawie wszystkiego, czego potrzebowałem aż do Lion na komputerach PPC - pakiet, port i źródło.
Seamus
2020-09-01 05:03:51 UTC
view on stackexchange narkive permalink

Zastanawiam się, jak należy instalować programy na komputerze Mac? Przez Homebrew lub oficjalny instalator, jeśli taki istnieje?

Inne odpowiedzi dotyczą różnych szczegółów. Ograniczę swoją odpowiedź do tego pytania, podam kilka zaleceń i pokrótce je wyjaśnię.

Rola menedżera pakietów w macOS

Myślę, że większość użytkowników różnych dystrybucji Linuksa i BSD doceniła wagę dobrego menedżera pakietów. Używam głównie dystrybucji opartych na Debianie i uważam, że menedżer pakietów ( aptitude ) jest tak samo niezbędny jak samo jądro. Rozumiem przez to, że gdyby menedżer pakietów nie istniał lub był zawodny i podatny na błędy, nie byłbym użytkownikiem Linuksa.

Firma Apple wybrała not, aby zapewnić menedżera pakietów per se . Apple zapewnia wybór narzędzi open source - są one dołączane do dystrybucji macOS i aktualizowane według uznania Apple. Ale istnieje ogromny świat dostępnego oprogramowania typu open source; większość z nich jest doskonałej jakości i oferuje znaczną przewagę nad oprogramowaniem o zamkniętym kodzie źródłowym.

Wydaje mi się, że w przypadku więcej niż 2-3 pakietów większość użytkowników najlepiej jest obsługiwać za pomocą menedżera pakietów. Niektóre pakiety bardzo dobrze obsługują instalację jednostanowiskową w systemie macOS. Niektóre nawet obsługują aktualizacje, a kilka także usuwa wsparcie. Ale nieuchronnie będą to inne, unikalne dla pakietu procedury, a konserwacja stanie się czasochłonnym obowiązkiem.

Porównanie szeroko stosowanych menedżerów pakietów w systemie macOS

Uważam, że w systemie macOS są powszechnie używane trzy menedżery pakietów:

Niektórzy nie zgodzą się z moim wyznaczeniem git jako menedżera pakietów. Nie będę twierdzić, że w ścisłym tego słowa znaczeniu git to oprogramowanie do kontroli wersji , ale czuję, że gdy git jest połączony z ogromnym kolekcje darmowych i otwartych repozytoriów, różnice wydają się zanikać w niejasnym żargonie.

Próbowałem Homebrew kilka lat temu i większość moich opinii ukształtowało się na podstawie tego doświadczenia. Mówiąc najprościej, pomimo faktu, że miałem pewne doświadczenie z menedżerami pakietów, kiedy po raz pierwszy wypróbowałem Homebrew , okazało się, że jest on niezręczny i zawodny. Lokalizacje pakietów, „ponownie włącz, wyłącz ponownie sudo , żargon odnoszący się do warzenia piwa: „brew = make?” , czym jest „beczka” ? i użycie Rubiego (co jest świetne, jeśli jesteś użytkownikiem, ale ja nie) wszystko przyczyniło się do braku atrakcyjności. Ale niektórzy to uwielbiają i dla tych ludzi powiem tylko: „Baw się, Garth”!

Wkrótce potem postanawiam wypróbować MacPorts i używam go od tamtej pory. Myślę, że wynika to głównie z faktu, że wydaje mi się to racjonalne, proste i łatwe w użyciu. Oferuje dużo głębi w nietypowych sytuacjach, które pojawiają się od czasu do czasu, ale osiągnięcie z nim produktywności wymaga tylko kilku minut i kilku poleceń; biegłość można osiągnąć w ciągu kilku godzin. Podsumowując, MacPorts to moja niezastrzeżona rekomendacja dotycząca czystego menedżera pakietów.

Kilka słów o git i dlaczego uważam, że jest to przydatny „menedżer pakietów” . Jako narzędzie do kontroli wersji git jest złożonym oprogramowaniem, którego opanowanie wymaga wiele wysiłku. Możesz to zrozumieć, przeglądając wiele stron man dla git i jego różnych podmiotów zależnych. Jednak użycie go do „instalacji” i aktualizacji pakietów hostowanych w repozytorium git (na przykład GitHub) wymaga tylko kilku poleceń. Uważam, że jest to przydatne przede wszystkim w dwóch sytuacjach:

  1. W przypadku pakietów (skrypt, dokumentacja itp.), które nie są dostępne na MacPorts
  2. Pakiety, dla których chcesz wprowadzić zmiany w kodzie & skompiluj samodzielnie
Italian Philosophers 4 Monica
2020-09-02 01:29:17 UTC
view on stackexchange narkive permalink

Ze względów bezpieczeństwa wolę macports / homebrew niż oficjalne instalatory.

Doszło do wielu incydentów, w których dostawcy / sprzedawcy oprogramowania włamali się na swoje serwery i do pobranych plików dodano złośliwe oprogramowanie.

Prawdopodobnie może się to również zdarzyć w macports / homebrew, ale różnica polega głównie na tym, że osoby opiekujące się tymi repozytoriami spodziewają się ciągłego złośliwego zachowania i można oczekiwać, że będą mieli pewne doświadczenie w powstrzymywaniu złych ludzi. Dużo gałek ocznych. Jeśli będzie gorzej, jest szansa, że ​​ktoś inny będzie miał problemy z macports / homebrew przede mną z powodu dużego ruchu.

Natomiast firma / programista, który głównie pisze pakiet oprogramowania, będzie miał przede wszystkim doświadczenie w pisaniu oprogramowania, a nie zabezpieczaniu serwerów pobierania. Teraz większość z nich prawdopodobnie mimo wszystko wykonuje bardzo dobrą robotę, ale musisz polegać na tym, że wszyscy zrobią to dobrze, zamiast tylko 1-2, macports i homebrew. Raz skompromitowany, może pozostać taki przez chwilę, zanim ludzie się o tym dowiedzą.

Możesz także szybko wygenerować raport nieaktualny port , aby wychwycić to, co wymaga poprawienia.

Ostatecznie za każdym razem, gdy coś instalujesz, podejmujesz pewne ryzyko. Słowo ostrzeżenia @ benwiggy jest tutaj całkowicie na miejscu.

mmmmmm
2020-09-02 23:42:09 UTC
view on stackexchange narkive permalink

Zależy, bym nie udzielił jednej odpowiedzi, z wyjątkiem mieszania homebrew i indywidualnych instalacji.

Jeśli jednak używasz Homebrew, nie możesz używać oficjalnych instalatorów w przypadkach takich jak node.Dzieje się tak, ponieważ zarówno homebrew, jak i node chcą używać / usr / local, który jest najczęstszym miejscem do instalowania stron trzecich oprogramowanie w systemach operacyjnych typu unix.Oprogramowanie do budowania stanowiska, np. Narzędzia automatyczne GNU, instaluje się tam domyślnie, więc większość instalatorów umieści je tam.Jeśli zainstalowałeś oprogramowanie innej firmy w tym katalogu, homebrew może się pomylić, zobacz pytania tutaj z wyjściem brew doctora.

Inne menedżery pakietów instalują się w innych katalogach, aby umożliwić korzystanie z / usr // local.Macports domyślnie używa / opt, ale może używać innych katalogów.Fink używa / sw



To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 4.0, w ramach której jest rozpowszechniana.
Loading...