Removendo o MacPorts e instalando o HomeBrew no Mac OS X

O MacPorts e o HomeBrew são gerenciadores de pacotes em linha de comando para o Mac OS X no mesmo estilo do apt-get para os sistemas baseados no Debian, ou o yum no Fedora, zipper no OpenSuse, emerge no Gentoo, swaret ou gslapt no Slackware etc 🙂

Quando comecei a fuçar no Mac OS, senti falta de um gerenciador de pacotes tal como o apt-get, que resolve facilmente as dependências dos pacotes e facilita imensamente o trabalho de se instalar programas no Linux. Depois de procurar um pouco acabei encontrando quatro opções:

Cada um desses programas tem suas características no tratamento das dependências dos pacotes e na forma de baixar, configurar e compilar; além disso, alguns são mais simples – como Rudix (que é dos brasileiros Rudá Moura e Leonardo Santagada), que já traz os pacotes pré-compilados e instala apenas os executáveis e outros mais sofisticados – como o MacPorts, o Fink e o HomeBrew. O MacPorts, por exemplo, é baseado no Ports do FreeBSD e é mantido com o apoio voluntário de alguns desenvolvedores da Apple – o que é bastante interessante, e recebe muitas contribuições dos usuários e tem uma biblioteca de programas bastante completa sendo (em minha opinião) a base de programas-fonte mais completa disponível para o Mac OS X.

Este artigo, no entando, tratará especificamente sobre a remoção do MacPorts (para um guia de instalação, clique aqui – em inglês) e a instalação do HomeBrew. Estou fazendo isso porque nos últimos tempos tenho encontrado alguns problemas de atualização do MacPorts e para não ficar muito tempo com o mesmo problema nas mãos, resolvi testar o HomeBrew para o gerenciamento dos programas que preciso instalar.

Antes de mais nada, é importante que você saiba que os procedimentos que vou tomar neste tutorial, irão remover completamente TODOS os pacotes que você instalou através do MacPorts, incluindo o próprio MacPorts. Além disso, algum programa que você tenha instalado sem utilizar o MacPorts e que utilize alguma biblioteca dinâmica instalada através dele, poderá deixar de funcionar. Então, você pode utilizar este tutorial apenas como uma última tentativa para resolver algum eventual problema. Faça por sua própria conta e risco!

Removendo o MacPorts

Para remover o MacPorts por completo, utilizaremos dois comandos, realizando a desinstalação em duas etapas:

  1. Removendo os pacotes que foram instalados: talvez você queira apenas “resetar” o MacPorts, removendo todos os pacotes instalados mas mantendo a instalação do MacPorts no seu Mac OS;
  2. Removendo a instalação do MacPorts: aí sim tudo o que o MacPorts tem será removido, incluindo os pacotes;

Para remover os pacotes instalados através do MacPorts, utilize o comando:

$ sudo port -fp uninstall installed

Com isso, os pacotes que você baixou pelo MacPorts (exemplo, sudo port install wget) serão removidos. Dependendo da quantidade de pacotes instalados, esta operação poderá demorar um pouco.

Para remover todo o MacPorts (e tudo que veio junto com ele), utilize o comando:

$ sudo rm -rf \
/opt/local \
/Applications/DarwinPorts \
/Applications/MacPorts \
/Library/LaunchDaemons/org.macports.* \
/Library/Receipts/DarwinPorts*.pkg \
/Library/Receipts/MacPorts*.pkg \
/Library/StartupItems/DarwinPortsStartup \
/Library/Tcl/darwinports1.0 \
/Library/Tcl/macports1.0 \
~/.macports

Depois disso, bye-bye MacPorts! Se o seu objetivo era remover o MacPorts, pode parar por aqui. Se quiser instalar o HomeBrew, basta seguir as instruções abaixo.

Instalando o HomeBrew

O HomeBrew, em comparação com o MacPorts, é mais espartano para instalar: ele não tem um instalador e tudo é feito via linha de comando. Na verdade ele tem um script de instalação que está disponível no GitHub. Para instalar, execute o comando no terminal (lembrando que para isto, você precisa do XCode Command Line Tools para ter acesso ao git, ruby, subversion etc):

$ ruby <(curl -fsSkL raw.github.com/mxcl/homebrew/go)

Instalação do HomeBrew: simples e rápida

É só isso, bem fácil e rápido. O complicado, vem depois.

Depois de baixar e instalar o HomeBrew, é ALTAMENTE recomendado executar o comando “brew doctor” antes mesmo de atualizar a base de dados do brew e instalar qualquer programa. O HomeBrew não utiliza o sudo para obter permissão de escrita em determinadas áreas do sistema; você pode utilizar fazer um “brew install wget” sem precisar ser root ou usar o sudo. Isso significa que ele escreve em áreas reservadas do sistema sem misturar os binários nativos do shell do Mac OS com os binários que você irá criar com a instalação de programas; além disso, ao invés de copiar os executáveis criados na compilação dos programas, ele apenas cria links simbólicos. Isso é um vantagem quando se quer manter o sistema saudável e minimamente organizado. Por isso é tão importante executar o “brew doctor” antes de mais nada:

$ brew doctor

Com isso, o “Doctor Brew” irá apontar uma série de problemas (principalmente de permissões) que você deve resolver antes de começar a usar o HomeBrew. Por exemplo:

Doutor Brew em ação: organizando o sistema

É bastante importante alientar que nesta situação cada um pode ter problemas diferentes apontados pelo “brew doctor”. No meu caso houve vários, mas eu pude resolver todos. Nos casos em que é necessário alterar a permissão como sugerido pela mensagem “You should probably `chown` them”, você poderá usar o seguindo comando:

$ sudo chow -R carlos /usr/local/share/man/*

Isso fará com que o usuário “carlos” se torne dono da pasta “man” em “/usr/local/share” e das pastas que estiverem dentro de “man” – este comando será executado recursivamente.

A menos que você tente resolver todos os problemas de uma só vez (se for possível), e importante que você execute o comando “brew doctor” novamente depois de tentar resolver o problema indicado, para ter certeza de que tudo está sendo resolvido. Tome muito cuidado com as bibliotecas dinâmicas – você pode apagá-las (o que não é uma boa idéia, a menos que você saiba o que está fazendo), pois com certeza irá estragar a instalação de algum outro programa. Por exemplo, no meu caso, eu havia instalado o programa ncargs (NCAR Graphics) no Mac OS X sem utilizar o MacPorts, mas alguns executáveis dele foram lincados com algumas bibliotecas dinâmicas do gfortran, que foi instalado pelo MacPorts. Resultado, o comando “ncl” do programa ncargs não funciona mais. Portanto, tome muito cuidado!!!

Outro ponto importante, é a configuração do seu PATH: talvez você tenha que adicionar dois caminhos utilizados pelo HomeBrew a ele. Por exemplo, no meu “.bas_profile” (que fica oculto no meu home), na última linha do arquivo eu adicionei o seguinte:

export PATH="/usr/local/sbin":${PATH}
export PATH="/usr/local/bin":${PATH}

Depois disso, basta salvar e fechar o arquivo e recarregar as variáveis de ambiente do seu shell:

$ source .bash_profile

Isso poderá auxiliar na solução dos problemas apontados pelo “brew doctor”.

Quando todos os problemas forem resolvidos, o “brew doctor” exibirá a seguinte mensagem:

Your system is raring to brew.

Com isso, tudo está pronto para o primeiro update e depois para a instalação dos seus programas. Para fazer o primeiro update, basta fazer:

$ brew update

E depois, se tudo der certo 😛 instale os programas que você precisar. Por exemplo, instale o programa wget:

$ brew install wget

Isso é tudo, se precisar de mais ajuda, basta digitar “brew –help” no terminal. Ah, o termo “FORMULA” utilizado pelo HomeBrew se refere a uma rotina para a instalação de algum programa. Portanto, se você digitar “brew install wget”, wget será o nome da FORMULA que você estará utilizando para instalar o pacote wget-1.14.tar.gz.

Apenas como curiosidade, o termo “HomeBrew” é utilizado para alguma coisa caseira, feita em casa.

Referências:

Anúncios

Ajustando a variável JAVA_HOME

Se você digitar algum comando no terminal que necessite das bibliotecas do JAVA e você sabe que elas estão instaladas, mas por algum motivo não funcionam corretamente, o problema pode ser com a variável JAVA_HOME. No Slackware, toda vez que eu tentava rodar um script de conexão VPN, me aparecia a seguinte mensagem:

bash-4.1# sh carlos.frederico.sh start
 which: no java in (/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:/bin:/usr/bin)
 Error: JRE_HOME is not defined correctly.
 We cannot execute

No entanto, quando eu tentava rodar como usuário comum, apenas utilizando o sudo, surgia uma outra mensagem:

carlos@darkstar:~/.keys/users/carlos.frederico$ sudo sh carlos.frederico.sh start
 Password:
 Checando atualizacoes
 VERSIONS.xml
 Nao ha atualizacoes
 Finalizando atualizacoes
 Lendo informacoes
 Enviando informacoes
 ACESSO LIBERADO
 Iniciando a VPN...
 carlos.frederico.sh: line 10: openvpn: command not found

Ou seja, o comando openvpn, embora instalado, não estava sendo executado porque dentro do script de execução da VPN, havia uma referência às bibliotecas do JAVA, que também estavam instaladas, mas mal configuradas.

Neste caso, quando dei um “echo $JAVA_HOME” na minha conta de usuário, o resultado foi “/usr/lib/java”, enquanto que na conta de root, nada apareceu! Para descobrir onde está instalado o java, basta dar um “whereis java”. Então, bastou adicionar as seguintes linhas no .bashrc no home da conta de root (se não existir, basta criar!) e voialà!

export JAVA_HOME="/usr/lib/java"
export PATH="/usr/lib/java/bin":${PATH}

Depois de adicionadas as variáveis, basta dar um source .bashrc para que as variáveis sejam exportadas.

Como e quando mudar de distribuição?

Antes de se autoproclamar “linuxuser”, todo linuxista já passou por pelo menos 3 distribuições diferentes: ou uma baseada no Slackware, ou uma baseada no Debian … ou uma baseada no SuSe ou RedHat. Certamente, estas são as três grandes distribuições que deram origem a todo o ecosistema de distribuições que temos hoje em dia. Nesse processo, toda mudança é uma verdadeira aventura no começo e à medida em que os conhecimentos vão sendo agragados, a brincadeira fica cada vez mais divertida. A minha primeira distribuição linux foi a saudosa Mandrake 8.2 Freq. que comprei na banca de jornal.

Naquela época, de internet discada, era quase que impossível baixar uma distribuição desse porte, a menos que fosse o Kurumin (mas ainda sim esperando algumas semanas para o download terminar!). Lembro-me que demorei algumas semanas tentando juntar um pouco de coragem para instalar no meu primeiro e novo computador. Que tempo aquele! Tudo era novo, nunca havia aberto o meu computador, o que também foi uma grande aventura… Depois de algum tempo pensando e depois de ter feito um belo backup em disquetes, estava pronto para a minha primeira experiência com o linux! As primeiras tentativas foram um tanto quanto emocionantes, com o medo cercando todo o momento de estragar o computador e acabar com a máquina dos sonhos de minha irmã e eu. Meu pai foi um grande incentivo, porque ele nunca reclamou dos meus experimentos. Depois de instalado o sistema, os primeiros desafios foram a placa de vídeo (uma nVidia GeForce MX 400 de 64 MB) e o modem (um LG com chipset Netodragon). A placa de vídeo foi barbada, mas apanhei para entender o que faziam os comandos no terminal. Essa segunda etapa foi um grande aprendizado, aprendi muito (para quem não sabia nada!). Depois de alguns meses de intensa pesquisa e muita persistência, finalmente consegui instalar o modem e assim inaugurei a minha era do linux com internet. Tudo foi muito fantástico! Depois do Mandrake, que eu acompanhei até a versão 10.0 (que eu comprei no GuiadoHardware!), vieram o Kurimun (diversas versões), o Slackware (desde a versão 8.0 até as mais atuais), o Debian (que sempre tentei, mas nunca conseguia instalar com sucesso – faltavam mais conhecimentos!), o Gentoo (que nunca consegui instalar devido à minha conexão discada…) e finalmente o Ubuntu (que uso até hoje, desde a versão 5.04) entre muitas outras distros menores e selvagens. Cheguei num ponto de pensar na minha própria distribuição, começando do zero mesmo (linux from scratch!) chamada Aetos Linux (Aetos é um nome legal, que significa pipa em grego (:D).

Depois dessa salada toda, a pergunta que fica é: quando e como mudar, experimentar, testar uma nova distribuição?

Há diversas maneiras de se fazer isso. Mas com o passar dos anos, aprendi que é sempre melhor fazer as coisas do jeito mais simples, sem pressa, pensando na produtividade, estabilidade e benefício. Certamente, os mais apressados instalam uma distribuição por cima da outra. Simples assim. Os mais apressados e também cautelosos, sempre mantém uma partição /home separada, assim os riscos são minimizados, mas não totalmente eliminados, pois ainda sim corre-se o risco de se cometer um erro crasso e formatar a partição errada… Há também a opção de se fazer dual boot (ou multiboot) e ter várias distribuições instaladas ao mesmo tempo, lado a lado. Eu mesmo já fiz isso e o meu recorde foi 4 distribuições, todas compartilhando o mesmo /home. Nisso, perde-se em espaço, mas hoje em dia com HD’s enormes, dá tranquilo para manter várias distribuições no mesmo HD sem ter que expremer os dados pessoais. Mesmo assim, o método mais seguro de se testar uma nova versão de uma determinada distribuição ou uma completa e nova distribuição, é utilizando uma máquina virtual.

A praticidade desta alternativa é bastante atrativa, visto que não se corre o risco de perder dados pessoais e pode-se tentar o quanto for necessário. Em contra-partida, a máquina hospedeira (host) tem que dividir os recursos (processador, memória, espaço em disco etc) com a máquina convidade (guest). Em máquinas mais antigas, a menos que se tenha pelo menos 1 GB de ram e um processador com pelo menos 1 GHz de frequência, não é uma boa idéia utilizar uma máquina virtual. Bons softwares (tanto para linux quanto para Windows) de virtualização, são o VirtualBox (meu preferido) e o VMware.

Ambos tem suas vantagens e desvantagens, o que acaba fazendo com que os usuários prefiram uma à outra. Em minha opinião, acho que o VirtualBox é mais flexível para os hosts linux do que o VMware. Mas esse papo é outra história…

Finalmente, resta-nos pensar quando mudar de distrubuição. Esta pergunta acaba sendo muito pessoal, e cada um sente uma necessidade diferente. No meu caso, por exemplo, sinto que as últimas versões do Ubuntu tem se distanciado bastante do projeto Gnome (meu gerenciador de janelas predileto). Isto me incomoda um pouco, apesar de que esta direção irá revelar mais um opção em termos de gerenciador de janelas, com seus atrativos etc. Imagine, então, que os usuários mais acostumados a anos de uso do Gnome, com todas as suas facilidades, vantagens e desvantagens, se encontrem perdidos em relação à distribuição que mais utilizam no trabalho, na escola ou no computador pessoal. Essa situação, para quem sempre tem as últimas atualizações (como eu), pode ser ruim porque os seus recursos computacionais pouco-a-pouco deixaram de ter o suporte que sempre tiveram. O que fazer então? Mudar de distribuição pode ser uma alternativa. Como o Ubuntu é baseado no Debian e este mantém firme e forte o Gnome, pode ser uma alternativa. Por outro lado, os pacotes disponíveis na versão estável do Debian são mais antigos e pode acontecer de alguns recursos que mais utilizava nas últimas versões do Gnome disponível no Ubuntu, ainda não estajam disponíveis na última versão do Debian… e por aí vai. Uma mudança mais drástica seria mudar completamente de distribuição, indo, por exemplo, para um Gentoo, ou um ArchLinux que são distribuições do tipo rolling release, ou seja, são frequentemente atualizadas. De novo, caímos na balança dos prós e contras. Isso sempre irá acontecer quando o assunto for “que distribuição utilizar” ou “quando mudar de distribuição”. Há alguns anos que uso linux no meu trabalho e há vários anos antes já utilizava em casa. Acabei me acostumando com o estilo Debian pela praticidade de instalação dos pacotes e resolução de dependências. Acabei me acostumando com o Gnome, pela levaza, simplicidade e o visual da biblioteca GTK, além dos aplicativos padrão. O que resta, então, é escolher uma nova distribuição que leve em conta estes fatores e torcer para que mais anos de uso contínuo venham pela frente!

Meus Computadores

Neste post aqui, mencionei a falta que sinto do meu antigo (e primeiro) Athlon Xp 1800+. Na verdade, sinto falta daquela época… Até este novo ano (2011), desde 2002 tive 5 computadores, sendo três desktops e 2 notebooks.

Como já disse, o meu primeiro computador foi um desktop, um Athlon XP 1800+ (socket 462) com as seguintes características:

  • Processador Athlon XP 1800+ de 32 bits (socket 462)
  • 128 MB de RAM PC 3200 (depois foram aumentadas para 768 MB)
  • Disco de 20 GB (depois de pifado tive outros dois de 80 GB)
  • Placa de vídeo AGP 4x nVidia GeForce MX 400 de 64 MB de RAM
  • Leitor de CD-ROM (depois comprei um gravador de CD e mais tarde, um de DVD)
  • Placa-mãe discreta (offboard) SOYO K7VTA PRO (ainda possuia um slot ISA!)

Sempre achei essa máquina o máximo. E foi sempre uma aventura também usá-la. Me lembro como se fosse hoje, a primeira vez que a abri, por mera curiosidade… Eu queria aprender, ver como funcionava por dentro, quais eram os componentes, e depois disso, nunca mais parei! Me lembro que minhas mãos suavam e que o suor acabaou manchando a lataria interna do gabinete… Que tempos aqueles… Fiquei com esse computador por uns 4 anos, e ele resistiu bem, até que os capacitores da placa mãe começaram a estufar… Que pena, que dó eu sentia (de mim mesmo, tornando-me órfão do meu próprio computador). Foi nesse computador que instalei pela primeira vez o Linux, na época era o Madrake 8.2, que eu havia comprado na banca, junto com a revista que ensinava a instalar… Que aventura, que época boa! Depois do Mandrake coloquei de tudo um pouco, Slackware (a partir da versão 9), Gentoo, Debian, as primeiras versões do Ubuntu e o saudoso Kurumin!!!

Depois que este computador entrou na UTI, tive que recorrer a outro. Logo em seguida, fui até a cidade e na loja propus ao dono a possibilidade de fazer um abatimento das peças que eu tinha (e que funcionavam) na compra de um computador mais novo… Era a vez do meu Semprom 2600 de 64 bits (socket 754)!

O Semprom, tinha as seguintes características:

  • Processador Semprom 2600 de 64 bits (socket 754)
  • 1 GB de RAM (dois pentes de 512 MB DDR1 Corsair, fantásticos!)
  • Disco de 80 GB
  • Placa de vídeo VIA onborad (logo em seguida comprei uma AGP 8x nVidia GeForce 6200 de 256 MB de RAM – sem turbo cache!)
  • Gravador de CD (herdei do velho Athlon, pois o de DVD havia pifado)
  • Placa-mãe onboard ECS K8M800-M2

Embora não fosse uma grande máquina, dava pro gasto. Na verdade era uma máquina bastante ordinária e sempre achei que o meu velho Athlon dava mais conta do recado do que o Semprom (mesmo este sendo mais moderno!). Fazer o quê, vamos atualizando… Depois de mais uns 3 anos de uso, eis que a bateria da placa-mãe começa a descarregar sistematicamente a cada dois ou três boots. Resultado, mais uma placa que vai para o beleléu… Acho que retificar placas-mãe não compensa, o resultado não me agrada.

Nesse meio tempo, tive também um Pentium Pro 100 MHz. Era um Itautec Infoway (só a CPU) que meu vizinho não queria mais. Ele tinha vários problemas (não ligava, quando ligava ele travava etc), mas de tanto fuçar acabei colocando ele pra funcionar. Ele tinha as seguintes características:

  • Processador Pentium Pro 100 MHz
  • 16 MB de RAM (quantidade razoável)
  • HD de 5 GB (quantidade mais do que suficiente para o Windows 3.1, 95 ou 98)
  • Leitor de CD-ROM
  • Placa de Som Sound-Blaster!
  • Placa de vídeo de alguns pouquíssimos MBs
  • Floppy

Confesso que fazia desse computador o meu laboratório. Enfiava tudo quanto é Linux nele só pra aprender a lidar com Hardware antigo (obsoleto mesmo). Hoje ele deve estar encostado na casa da minha irmã, em algum lugar, coberto pela poeira e pela solidão… :S

Depois destes 3 desktops (2 que eu realmente usei para produzir), chegava a hora e a oportunidade de ter um notebook. Preços mais acessíveis, condições especiais… Qual comprar? Nessa época eu já morava em Cachoeira Paulista e estava cursando o mestrado. Fui até as lojas Cem e escolhi um STI IS 1462. Este notebook tem as seguintes características:

  • Processador Pentium Dual Core de 1.8 GHz (já com dois núcleos)
  • 1 GB de RAM DDR2 (depois aumentei para 1,5 GB)
  • HD de 120 GB (depois aumentei para 320 GB)
  • Placa de vídeo VIA Chrome 9 HC IGP (ordinária, sem comentários…)

Usei ao extremo esse notebook durante o meu mestrado. Meu sentimento por ele é de raiva (na verdade por mim mesmo) e de agradecimento, por ter me acompanhado durante a empreitada do mestrado e ter produzido minha dissertação. De tantas dificultades que tive com ele, cheguei a fazer um site dedicado, onde mostro como instalar o Linux, alguns truques e também fotos dele desmontado, dissecado.

Atualmente, em substituição ao STI, adquiri um HP G42, pois já não aguentava toda a marra que o STI IS 1462 me proporcionava… O HP é o mais modernoso, em todos os sentidos. Ele tem as seguintes características:

  • Processador Intel Core i3 de 2.27 GHz (dual core real, mas emula mais dois núcleos, total de 4!)
  • 3 GB de RAM DDR3 (máximo de 8GB!)
  • HD de 500 GB (uma infinidade finita de espaço…)
  • Placa de vídeo Intel HD Graphics (com saída HDMI, fraca mas muito legal, funciona com tudo!)

A Helena (minha namorada), tinha um desktop também. Era um Athlon XP 2600+, muito parecido com o meu. A placa mão dele era uma Asus (não me lembro o modelo), mas era um modelo muito ruim, queimava sempre as fontes, terrível… Até que ela comprou também um noteboos, um Acer para substituílo. Resumindo, tenho dois processadores Athlon XP lá um casa (duas relíquias que ninguém quer): um TBred 2600+ e um Barton 2600+ 🙂 Se alguém se interessar…

Em resumo, estou bastante satisfeito com meu notebook atual. Rodo exclusivamente Ubuntu Linux nele e realmente é rápido e eficiente. Mas mesmo assim, sinto que um bom para tarefas mais árduas como rodar um modelo ou qualquer outra tarefa que exija mais processamento. Por mais rápido que seja o processador do notebook, ele nunca será tão eficiente quanto o de um desktop, por mais lento que este seja. Ainda sim, tenho em casa os restos mortais do meu Sempron, que de vez em quanto brinco de laboratório, mas acho que este tempo já passou!