MacPorts, Fink 및 Homebrew의 장단점은 무엇입니까?

확실히 Homebrew입니다. 나는 Fink로 시작한 다음 MacPorts (더 행복 함), Homebrew (훨씬 더 행복 함)로 전환했습니다. 각각을 사용하는 이유는 다음과 같습니다 (원하는 경우 전문가 목록).

Fink

• Apt 기반-Debian 기반에서 온 경우 집처럼 편안합니다. 환경
• 바이너리 패키지-패키지는 바이너리로 사용할 수 있으므로 컴파일 시간이 길지 않습니다. 실제로 사전 컴파일 된 바이너리가 항상 구식이라는 것을 알았지 만 어쨌든 내 시스템을 위해 무언가를 컴파일해야했습니다

MacPorts

• 자작과 달리 향후 변경 될 수있는 MacOS 라이브러리에 의존하지 않습니다.
• / opt / local에 모두 설치
• Nice 변형 시스템 빌드를 사용자 정의 할 수 있습니다.
• 쉽고 직관적 인 포트 파일을 추가 할 수도 있습니다.
• PowerPC 버전을 포함하여 Tiger로 돌아가는 OSX 및 macOS의 여러 버전을 지원합니다. 기타 답변

Homebrew

• OS X와 함께 제공되는 기능을 최대한 활용합니다. Fink 또는 MacPorts는 작은 Ruby 기반 도구를 설치하기 위해 처음부터 Ruby 및 라이브러리를 빌드 / 설치할 필요가 없습니다.
• /usr/local
• 루트 액세스없이 설치
• 설치된 모든 패키지는 자체 셀러에 깔끔하게 샌드 박스 처리되어 있으므로 bin, man 등의 심볼릭 링크 만 있으면됩니다.
• 가이드 및 자동화 기능이있어 자신 만의 공식 파일을 만들 수 있습니다. (즉. 패키지 설명자)
• 루비로 작성되었으며 모든 공식은 간결한 루비 스크립트입니다.
• 사전 컴파일 된 바이너리로 인한 빠른 설치

pkgin

• 사전 컴파일 된 바이너리로 인한 빠른 설치
• / opt / pkg /에 설치된 모든 항목
• pkgsrc 커뮤니티 및 Joyent 지원
• NetBSD, DragonFly BSD, Solaris, Debian, Mac OS X, Minix

https://pkgsrc.joyent.com/install-on-osx/

http://pkgin.net/

댓글

• 설명은 확장 된 토론을위한 것이 아닙니다. 이 대화는 채팅으로 이동 되었습니다. 잠금을 해제해야하는 경우 다른 메타 요청 또는 플래그를 사용하여 문제를 제기하세요.

MacPorts

Mac OS X와 더 독립적입니다. 즉, MacPorts는 이미 많은 시스템 라이브러리와 소프트웨어를 무시합니다. Mac OS X에서 사용할 수 있으며 대신 자체 코드를 가져옵니다 . 설치하는 유틸리티에 대규모 라이브러리 및 소프트웨어 세트가 필요한 경우 속도가 느려질 수 있습니다.

그러나 이러한 종류의 선택은 설치 한 패키지가 Apple의 시스템 업데이트 / 업그레이드의 영향을 덜 받기 때문에 더 안전합니다.

Homebrew

기존 Mac OS X 설치 패키지에 더 많이 의존하므로 패키지 설치 속도를 높이고 중복 라이브러리를 최소화합니다.

그러나 위험은 설치된 패키지가 손상 될 수 있습니다. n Apple의 시스템 업데이트 / 업그레이드 때문입니다.

따라서 두 가지 다른 종류의 트레이드 오프가 있습니다.

또한 Homebrew가 / usr / local 기본적으로, 일부 사람들은 이것을 좋아하지 않습니다 . 유닉스 전통과 충돌하며 이미 설치된 경우 문제가 발생할 수 있습니다 (MySQL 등).)

이러한 차이점을 제외하고이 두 패키지가 제공 할 수있는 패키지를 고려하면 현재 제공 한 패키지를 보여주는 MacPorts / Homebrew가 이미 설치되어있는 경우 다음 두 명령으로 확인할 수 있습니다.

port list | wc -l brew search | wc -l 

MacPorts에는 Homebrew보다 더 많은 패키지가 있다는 것을 알게 될 것입니다.

(2016 년 5 월 13 일 19399 vs 3583)

코멘트

• 다양한 패키지 수에 대한 언급 : Homebrew는 자체 패키징 시스템 (rubygems / pip / cpan…) 또는 더 적절한 OS X 설치 프로그램을 사용할 수있는 소프트웨어 (MacTeX). 또한 중복 및 이전 버전은 기본 저장소에 없지만 대체 탭 저장소에 포함됩니다. 예를 들어 포함 된 모든 Python 버전에 대한 IPython 포트를 포함하는 macports와 비교하십시오. 그것은 맥 포트의 패키지 수를 자연스럽게 증가시키는 일종의 다른 철학입니다.
• 훌륭한 링크! terrychay.com/article/macports-vs-homebrew.shtml 감사합니다!
• @YaOz, 확실히 homebrew를 변경하여 무언가를 사용할 수 있습니다. /usr/local가 아닌 다른가요?
• @Pacerier /usr/local/가 아닌 다른 곳은 “지원되지 않음”또는 “권장되지 않음”이라고 생각합니다. .

적어도 2014 년 말쯤에는 진실처럼 보이는 내 생각을 추가합니다. .

2 년 전부터 Homebrew는 마인드 쉐어 측면에서 확실히 우위를 점하고 있습니다. 사람들이 Homebrew로 얼마나 행복했는지에 대해 이야기하는 많은 블로그를 찾을 수 있습니다. 일반적으로 전체 “MacPorts가 전 세계를 끌어들입니다”와 “Homebrew가 이미 가지고있는 것을 활용합니다”때문입니다.

하지만 IMO에서 MacPorts는 몇 년 전과는 다른 괴물입니다. 처음 OS X로 전환했을 때 & MacPorts를 사용하고 있었을 때 MP 철학은 정말 실망 스러웠습니다. 거의 모든 것이 소스에서 빌드 되었기 때문입니다. 새 설치는 특히 고통스럽고 느 렸습니다.하지만 지난 1 년 동안 순전히 내 인상을 바탕으로 MP 패키지의 90 %가 바이너리 인 것 같습니다. & 그래서 설치는 실제로 정말 빠릅니다. 제가 수집 한 내용에서 Homebrew는 “Bottles”로도이 방향으로 이동하고 있지만이 시점에서 HB를 통해 설치하는 대부분의 것은 소스에서 컴파일된다는 인상을 받았습니다.

따라서 반대 의견을 제시하기 위해서만 MacPorts는 실제로 “더 빠른”o 요즈음. 그러나 MP에 대한 대부분의 사람들의 의견은 2011-12 년경의 경험을 바탕으로 한 것 같습니다. & 실제로 이것을 고려하지 않습니다. 비록 내가 일반 HB 사용자가 아니기 때문에 (그리고 양쪽을 나란히 사용하는 것이 다소 고통스럽기 때문에) 이것을 소금과 함께 가져 가십시오.

HB가 아마도 “이길 것”이라는 장점이 있다고 생각합니다. 하지만 장기적으로는 전쟁 “이라는 말이 있습니다.

• HB는 모두 Ruby 인 반면 MacPorts와 패키지 공식은 TCL로 작성되었습니다. 이는 정확히 대중적인 스크립팅 언어가 아닙니다. 나만의 포트 파일을 만드는 것은 매우 간단합니다.
• HB는 GitHub를 기반으로합니다. & 따라서 MacPorts는 어딘가에 자체 SVN 저장소를 호스팅하는 반면 새로운 기여자에게는 훨씬 더 환영받는 것처럼 보입니다. 기본적으로 두 프로젝트의 서로 다른 연령을 반영한다고 생각합니다.
• 일반적인 합의는 MacPorts가 HB &로 대체되었다는 것입니다. 잘못하면 더 많은 사람들을 끌어 들이고 있습니다.

그렇지 않으면 YaOZl & kLy는 sudo, 종속성 등의 주요 차이점을 꽤 잘 다루었습니다. 나 MacPorts는 /opt/local에 아무것도 없을 것으로 예상하는 다른 프로그램, 루트 권한 등으로 설치되는 항목 등으로 인해 때때로 골칫거리가 될 수 있습니다. & 일반적으로 MacPorts와 함께 설치되지 않는 것이 가장 좋은 것들이 있습니다 (예 : MacPorts를 통해 Rails를 설치할 수 있지만 Ruby의 일반 Gem 관리를 통해 설치하지 않는 것은 미친 짓입니다.) 그 외에는 미리 패키징 된 OS X 라이브러리에 의존하지 않고 자신 만의 작은 세계를 구축하는 MacPorts 철학의 열렬한 팬이지만 &-작동하고 대부분 작동 할 때 정말 간단합니다. 패키지 관리자가 정말 원하는 것입니다. 제가 언급했듯이이 시점에서는 대부분의 항목을 설정하는 것이 매우 빠릅니다.

그 중 일부가 유용하기를 바랍니다.

댓글

• ” 일반적인 합의는 MacPorts가 HB

  , 옳든 그르 든 더 많은 사람들을 끌어 당깁니다. ” … 이것은 매우 피상적 인 말처럼 느껴집니다 …인기와 품질 제공은 같지 않으며 두 번째가 첫 번째로 ” 대체 됨 “을 의미하지는 않습니다.

• MacPorts는 이제 Github를 사용하고 있습니다. guide.macports.org/#project.github : ” MacPorts 프로젝트는 Git 분산 버전 제어 시스템을 사용합니다. 전체 프로젝트의 코드를 관리합니다. 마스터 리포지토리는 GitHub에서 호스팅됩니다. MacPorts 시스템 자체, MacPorts 포트 및 지금 읽고있는 가이드를위한 GitHub 저장소를 포함하여 거의 모든 프로젝트 코드 및 문서에 대한 공용 저장소를 유지합니다. ”

다른 답변 (지금까지)에서 언급하지 않은 것으로 보이는 것은 MacPorts입니다. macOS의 레거시 버전을 훌륭하게 지원합니다. Homebrew는 현재 Apple에서 지원하는 OS (일반적으로 마지막 3 개 릴리스를 의미 함) 만 지원합니다. 예를 들어 2020 년 8 월 현재 Catalina, Mojave 및 High Sierra 만 Homebrew와 호환됩니다.

반대로 MacPorts는 Tiger (!)에 설치할 수 있으며 프로젝트는 소프트웨어를 유지하기 위해 특별한 패치를 유지합니다. 가능한 한 일하고 있습니다. 또한 새 버전의 macOS에서 이전 버전으로 기호를 백 포트하는 ” 레거시 지원 ” 라이브러리를 유지합니다. 컴파일하는 동안이 라이브러리에 연결하면 모든 종류의 새 소프트웨어가 갑자기 이전 시스템에서 작동하게 될 수 있습니다.

그러므로 이전 버전의 macOS를 실행 중이거나 계속 유지해야한다고 생각하는 경우 Apple의 만료일이 지난 현재 OS는 MacPorts를 사용해야하는 이유입니다.

Brew는 완전히 사용하기에 부드럽기 때문에 단점에 대해 말할 수 없습니다. MacPorts의 몇 가지 단점 :

• Apple 개발자 사이트에서 Xcode를 설치해야 , 따라서 Apple 개발자 계정이 있어야합니다. (이제 신용 카드가 필요함) 거의 3.5GB의 항목을 다운로드합니다.
• 포트 873 (rsync)이 방화벽에 의해 차단 된 경우 “ HTTPS 프로토콜을 수동으로 구성 ;
• 패키지를 다운로드하는 HTTP (S) 서버는 (종종) 매우 느립니다 (어제 20KiB / s 미만, 매우 안정적인 기가비트에서 테스트 됨) 다른 국가의 연결) 및 오류 작업이 너무 느려서 실패 할 수 있습니다. 전송 된 마지막 60 초 동안 초당 1024 바이트 미만 으로 모든 것을 처음부터 다시 실행해야합니다.

처음 두 가지 요점에 대해 매우 인기있는 몇 가지 질문이 있습니다.

댓글

• 내 경험이었습니다. 10.6에 ImageMagick 설치, 양조는 매우 쉬웠지만 ‘ JP2 델리게이트를 포함하지 않습니다. imagemagick.org/script/binary-releases.php
• brew 및 macports에는 Xcode 명령 줄 도구 만 필요하므로 여기서도 동일합니다.
• @Mark I ‘ 무슨 뜻인지 잘 모르겠지만 brew는 Xcode 없이는 완벽하게 작동했습니다.
• 당신 ‘는 Xcode 명령 줄 도구를 통해 설치할 수있는 brew 및 MacPort 용 컴파일러가 필요합니다. Xcode 애플리케이션 이 필요하지 않습니다.
• 방화벽 뒤에있을 때 동기화하는 것이 얼마나 추악한 지 잊었습니다 … 이크 스!