Zmuszasz koegzystencję Homebrew i Macports?

Mam system MacOSX, z którego korzystam od wielu lat, i w tym czasie zainstalowałem sporo pakietów za pośrednictwem Macports.

Chcę teraz wypróbować Homebrew, ale z tego, co przeczytałem tutaj i gdzie indziej, jasno wynika, że domyślne instalacje Homebrew i Macports nie mogą z łatwością współistnieć.

Nie jest dla mnie opłacalną opcją odinstalowania Macports, ponieważ większość mojej codziennej pracy z MacOSX polega na korzystaniu z różnych narzędzi zainstalowanych na Macports. Co więcej, wiele moich własnych, domowych narzędzi jest teraz współzależnych z Macports. I wreszcie, wiele plików wykonywalnych i bibliotek współdzielonych, których rutynowo używam, jest teraz zainstalowanych w / usr / local, a mój system szybko stałby się bezużyteczny, jeśli wyczyściłem to drzewo katalogów.

Moje pytanie brzmi więc: czy ktoś wpadł na alternatywny sposób instalacji Homebrew, który może współistnieć z Macports? W szczególności, czy ktoś wymyślił, jak sprawić, by Homebrew wykorzystywał drzewo katalogów, takie jak / usr / local / homebrew zamiast / usr / local?

Z góry dziękuję za wszelkie sugestie lub wskazówki do dokumentów.

macos macports homebrew

— HippoMan
źródło

Jeśli chcesz po prostu spróbować, dlaczego nie skonfigurować maszyny wirtualnej z systemem OS X? Nie jest to sprzeczne z warunkami Apple dla OS X 10.7 i możesz eksperymentować z tym, co chcesz. Nawet jeśli to działa równolegle, nie zdziwiłbym się, gdyby wszystko zaczęło się psuć ...

— Daniel Beck

Dziękuję bardzo, ale wolę, aby oba menedżery pakietów działały w tym samym środowisku OSX, jeśli jest na to jakikolwiek sposób. Jest tak, ponieważ jeśli podoba mi się Homebrew, będę chciał stopniowo instalować pakiety za pośrednictwem tego systemu i stopniowo odinstalowywać stare pakiety oparte na Macports. Niestety, nie jest realną alternatywą dla mnie, aby zdecydować się na Homebrew, zdmuchnąć cały mój stary kod Macports za jednym zamachem, a następnie walczyć o zastąpienie go innym za pomocą Homebrew.

— HippoMan

Odpowiedzi:

Możesz powiedzieć Homebrew, aby używał własnego katalogu, a następnie dodać go do ścieżki. Chociaż nie do tego samego celu, ten fragment przewodnika instalacji mówi:

Wiele instalacji

Utwórz instalację Homebrew, gdziekolwiek rozpakujesz archiwum. Jakakolwiek komenda brew jest wywoływana, miejsce instalacji pakietów. Możesz użyć tego, co uważasz za stosowne, np. Systemowy zestaw bibliotek w / usr / local i poprawione formuły do programowania w ~ / homebrew

Źródło: https://github.com/mxcl/homebrew/wiki/installation

— Karolos
źródło

Dziękuję Karolos. Poniższa wypowiedź na tej samej stronie wiki nie zachęca mnie: „Jednak wyświadcz sobie przysługę i zainstaluj w / usr / local ... Wybierz inny prefiks na własne ryzyko! ” Ale spróbuję i zdam relację później.

— HippoMan

Próbowałem zainstalować homebrew w / usr / local / homebrew. Jednak niektóre pakiety, które próbuję zainstalować, zawodzą. Kiedy uruchamiam / usr / local / homebrew / bin / brew doctor , otrzymuję odniesienia do dosłownie dziesiątek nieoczekiwanych dylib, bibliotek statycznych, plików .pc i .la, a także ostrzeżeń o niektórych pakietach wymagających instalacji / usr / local. Ponieważ mój system w ogóle nie uruchomi się, jeśli zdmuchnę starsze instalacje oprogramowania (stąd pochodzi większość tych „nieoczekiwanych” plików), wygląda na to, że nie ma sposobu, aby użyć homebrew w moim systemie. No cóż ... (westchnienie) ...

— HippoMan

@HippoMan: Przepraszam, że to nie działa. Jedno pytanie: czy / usr / local / homebrew jest poprawnie skonfigurowany na twoich ścieżkach? tj. ŚCIEŻKA i (DY) LD_LIBRARY_PATH

— Karolos

@HippoMan: Które pakiety zawodzą? Właśnie próbowałem zainstalować kilka z nich i nie zauważyłem żadnego problemu (po edycji / etc / paths, aby dodać / usr / local / homebrew / bin).

— Karolos

Tak, mam poprawnie skonfigurowane PATH i LD_LIBRARY_PATH, aby wskazywały bin i lib w drzewie / usr / local / homebrew. Jednym z pakietów, które się nie powiodły, jest gawk, co jest warunkiem wstępnym avidemux. Ale zrestartuję się od zera i spróbuję jeszcze raz, na wypadek, gdyby popełniłem jakiś błąd.

— HippoMan

Moim sposobem wymuszenia ich współistnienia jest to, aby MacPorts nie był domyślnie widoczny, ale widoczny podczas wywoływania jakichkolwiek programów MacPorts. Oznacza to, że owiń programy MacPorts skryptem:

if [ "$#" -le 0 ]; then
  echo "Usage: $0 command [arg1, arg2, ...]" >&2
  exit 1
fi
if [[ -z $MACPORTS_PREFIX ]]; then
  MACPORTS_PREFIX='/opt/local'
fi
export PATH="$MACPORTS_PREFIX/bin:$MACPORTS_PREFIX/sbin:$PATH"
export DYLD_LIBRARY_PATH="$MACPORTS_PREFIX/lib:$DYLD_LIBRARY_PATH"
export CPATH="$MACPORTS_PREFIX/include:$CPATH"
command=$1
shift
exec $command $*

Jeśli nazwiesz ten skrypt jako macports.sh, możesz wykonać zawijanie przez macports.sh macports_bin, na przykład, macports.sh portbędzie on uruchamiany w portpakiecie.

Dla wygody można umieścić macports.sh somethingw niektórych skryptach o takiej samej nazwie, jak nakazuje się i umieścić je w swoim katalogu domowym, takich jak ~/bin, ~/.local/binitp

O tym pisałem na blogu miesiąc temu. Możesz go przeczytać, jeśli potrzebujesz szczegółowych informacji.

— xuhdev
źródło