Mac OS X - instalando software via DMG vs. estilo de linha de comando * nix

Question

Novo proprietário do Mac aqui, mas há muito tempo usuário do Linux. Alguém pode descrever para mim as diferenças entre a instalação de um software, como o Subversion, a partir de uma imagem .dmg em vez de compilar e instalar a partir da origem na linha de comando? O software acaba no mesmo local? Quais outras diferenças existem, como procedimentos de desinstalação? O que você consideraria os prós / contras de uma abordagem sobre a outra?

    

Answer 1

Um .dmg é apenas um disco virtual ("imagem de disco") e, por si só, não tem nada a ver com a instalação.

Quando a imagem de disco contém apenas uma aplicação (normalmente haverá algum texto explicativo pedindo para você arrastá-la para a sua pasta Aplicativos), então todos os arquivos de código e de suporte estão contidos naquele arquivo. O aplicativo é responsável por fazer qualquer configuração no primeiro lançamento e responsável por fornecer um mecanismo de desinstalação se qualquer coisa for instalado posteriormente. Muitos desenvolvedores estão usando a estrutura Sparkle para encontrar e instalar atualizações.

Se a imagem do disco contiver um pacote ( .pkg ou .mpkg ), esse é um instalador. A execução pode instalar arquivos em qualquer lugar do sistema e executar scripts de pré e pós-instalação, e não há mecanismo de desinstalação ou de atualização interno (o sistema mantém um log de pacotes instalados, portanto, se você executar um pacote de instalação posteriormente para uma versão mais recente do software, ele pode se comportar de maneira diferente do que se tivesse sido uma primeira instalação). Neste caso, também, o desenvolvedor é responsável por desinstalar e responder por atualizações. Desenvolvedores responsáveis instalarão em diretórios padrão ( /Applications , /Library e ~/Library , /usr , etc.)

Para softwares de linha de comando que você normalmente instala da origem, eu recomendaria um gerenciador de pacotes como MacPorts (minha preferência) ou Fink usando um pacote de instalação. Ambos os gerenciadores de pacotes configuram um diretório independente ( /opt e /sw , respectivamente) com todos os arquivos de suporte e código executável do software que instalam (e a maioria dos pacotes o respeita) e adicionam-se ao seu $PATH . Uma grande vantagem de usar um gerenciador de pacotes é que ele rastreia o software instalado e oferece a capacidade de atualizá-lo ou desinstalá-lo.

    

Answer 2

Instalar a partir de um .dmg normalmente é apenas arrastar e soltar para / Applications. Desinstalar é um ponto dolorido na experiência do Mac, na minha opinião. Você pode excluir o arquivo dos Aplicativos, mas somente esse material encapsulado no wrapper .app será removido. Quaisquer arquivos de configuração adicionais não desaparecem.

Outro caminho de instalação que você deve considerar é MacPorts e / ou Fink . Estes são um pouco semelhantes ao apt-get ou yum no mundo linux. Eles fornecem um utilitário de linha de comando para pegar, compilar e instalar software comum. Geralmente é tão simples como:

$ sudo port install svn

(exemplo do macport)

    

Answer 3

Isso é um pouco complicado, porque dentro do DMG pode haver uma simples solução de arrastar e soltar, ou um . PKG, que pode instalar coisas em qualquer local. .pkg normalmente deixa recitatos (normalmente em / Library / Receipts), embora o OS X não ofereça uma maneira fácil de gerenciar esses arquivos.

O Pacifist é um aplicativo útil que examina arquivos .pkg (que muitos aplicativos de linha de comando usam para locais de instalação personalizados) antes da instalação, para que você possa entender exatamente onde as coisas podem ser instaladas. Você pode determinar se sua versão auto-compilada será instalada no mesmo local ou não, e se eles entrarão em conflito com as versões do sistema:

link

Especificamente, você precisará garantir que, se eles forem instalados em locais diferentes, o caminho reflete a versão desejada que você deseja usar. Eu suspeito que a subversão não deve ser problemática com várias versões instaladas ... Para Ruby, eu uso um nome ruby19 para o executável ruby para parar qualquer problema de caminho com código incompatível.

Existe um plug-in quicklook menos poderoso, mas gratuito, para arquivos .pkg, que faz o trabalho básico de mostrar onde as coisas serão instaladas:

link