Mac OS X — установка программного обеспечения через DMG по сравнению с командной строкой *nix

Mac OS X — установка программного обеспечения через DMG по сравнению с командной строкой *nix

Я новый владелец Mac, но давний пользователь Linux. Может ли кто-нибудь описать мне разницу между установкой программного обеспечения, например Subversion, из образа .dmg и компиляцией и установкой из исходного кода в командной строке? Оказывается ли программное обеспечение в том же месте? Какие еще существуют различия, например, процедуры удаления? Каковы, по вашему мнению, плюсы/минусы одного подхода по сравнению с другим?

решение1

A .dmg— это всего лишь виртуальный диск («образ диска»), и сам по себе он не имеет никакого отношения к установке.

Когда образ диска содержит только приложение (обычно там будет некий пояснительный текст с просьбой перетащить его в папку Applications), то весь код и файлы поддержки содержатся в этом одном файле. Приложение отвечает за выполнение любой настройки при первом запуске и отвечает за предоставление механизма удаления, если что-тоявляетсяустановлен позже. Многие разработчики используютИскрафреймворк для поиска и установки обновлений.

Если образ диска содержит пакет ( .pkgили .mpkg), это установщик. Запуск его может установить файлы в любом месте вашей системы и запустить пред- и пост-инсталляционные скрипты, и нет встроенного механизма удаления или обновления (система ведет журнал установленных пакетов, так что если вы позже запустите пакет установщика для более новой версии программного обеспечения, он может вести себя иначе, чем если бы это была первая установка). В этом случае разработчик также несет ответственность за удаление и отвечает за обновления. Ответственные разработчики будут устанавливать в стандартные каталоги ( /Applications, /Libraryи ~/Library, /usr, и т. д.)

Для программного обеспечения командной строки, которое вы обычно устанавливаете из исходного кода, я бы рекомендовал менеджер пакетов, напримерMacPorts(мое предпочтение) илиФинкпо сравнению с использованием установочного пакета. Оба этих менеджера пакетов создают автономный каталог ( /optи /sw, соответственно) со всеми файлами поддержки и исполняемым кодом для программного обеспечения, которое они устанавливают (и большинство пакетов это уважают), и добавляют себя в ваш $PATH. Огромным преимуществом использования менеджера пакетов является то, что он будет отслеживать установленное программное обеспечение и даст вам возможность обновлять или удалять его.

решение2

Установка из .dmg обычно заключается в простом перетаскивании в /Applications. Деинсталляция — это, по моему мнению, одна из болевых точек в опыте работы с Mac. Вы можете удалить файл из Applications, но только то, что инкапсулировано в оболочке .app, исчезнет. Любые дополнительные файлы конфигурации не исчезают.

Другой способ установки, который вам следует рассмотреть, этоMacPortsи/илиФинк. Они чем-то похожи на apt-get или yum в мире Linux. Они предоставляют утилиту командной строки для захвата, компиляции и установки распространенного программного обеспечения. Обычно это так же просто, как:

$ sudo port install svn

(пример macport)

решение3

Это несколько сложно, потому что внутри DMG может быть простое решение «перетаскивания» или.PKG, который может устанавливать вещи в любом месте.Файлы .pkg обычно оставляют квитанции (обычно в /Library/Receipts), хотя OS X не предлагает простого способа управления этими рецептами.

Pacifist — полезное приложение, которое проверяет файлы .pkg (которые многие приложения командной строки используют для пользовательских мест установки) перед установкой, чтобы вы могли точно понять, где что может быть установлено. Затем вы можете определить, будет ли ваша самокомпилированная версия установлена ​​в том же месте или нет, и будут ли они конфликтовать с системными версиями:

http://www.charlessoft.com/

В частности, вам нужно будет убедиться, что если они устанавливаются в разных местах, ваш путь отражает желаемую версию, которую вы хотите использовать. Я подозреваю, что у subversion не должно быть проблем с несколькими установленными версиями... Для Ruby я использую имя ruby19 для исполняемого файла ruby, чтобы предотвратить любые проблемы с путями с несовместимым кодом.

Существует менее мощный, но бесплатный плагин для быстрого просмотра файлов .pkg, который выполняет основную работу по показу мест установки:

http://www.mothersruin.com/software/SuspiciousPackage/

Связанный контент