gem vs apt-get em um ambiente de servidor

Question

Onde devo desenhar a linha entre o uso do apt-get e gem ao configurar um servidor para hospedar ruby on rails com passageiro + apache?

Isso importa mesmo?

Parece errado misturar sistemas de gerenciamento de pacotes ao considerar atualizações de software e assim por diante.

Como alguém deve fazer isso?

    

Answer 1

Eu não uso o apt-get enquanto executo o NetBSD, mas o "pkgsrc" tem um papel similar ao apt-get.

Minha política local é muito simples. Se eu posso usar uma gema, eu uso uma gema. Se eu não puder, eu obtenho do pkgsrc. Algumas coisas que requerem código nativo (sqlite, alguns outros) simplesmente não são instaladas como gems fora da caixa.

O benefício major que eu vejo usando uma gem para a maioria das coisas é que posso ter mais de uma versão instalada de uma só vez. Por exemplo, eu tenho 3 versões diferentes do Rails instaladas, e os aplicativos podem ser migrados lentamente de um para outro.

Não tenho certeza se o apt-get permitiria que você fizesse isso, mas eu sei que o pkgsrc não faz isso. É um recurso que preciso e uso.

    

Answer 2

Uma coisa a ter em mente é que as atualizações acontecerão muito mais rápido usando gem do que nos repositórios oficiais do apt. Talvez existam repositórios de terceiros mais atualizados, não tenho certeza. No entanto, minha impressão é que, se você precisar de uma novidade de última geração, atualize usando gem.

    

Answer 3

Nossa política é que usamos gemas quando não há debs "downstream" na cadeia de dependências (normalmente código implantado e gerenciado pelo cliente), mas tudo o que fazemos é empacotado de maneira apropriada e, por isso, adicionamos quaisquer gemas dependentes debs para satisfazer essas dependências. Os diferentes sistemas de embalagem não devem ser um problema; sua ferramenta de automação de gerenciamento de sistemas deve ser capaz de lidar com as diferenças normalmente.

    

Answer 4

Eu desenho a linha na areia em atualizações rápidas vs estáveis está ok

Exemplo eu implanto no hardy, se o Ruby 1.8.6 é aceitável, caso contrário, o mais recente Ubuntu lançado se eu precisar 1.8.7

Eu então instalo o tarball do rubygems enquanto você precisa da versão mais próxima do Rails 2.3.4, e então instala o passageiro etc usando gems.

Situações como o rmagick, onde você precisa ter o imagemagick instalado, eu uso o debs do sistema para o imagemagick e, em seguida, instalo o gem rmagick

    

Answer 5

Criar debs a partir de gemas pode ser automatizado. Pacotes Python, OCaml, Cabal e CPAN são diretos. O debgem é um serviço gem-to-deb com pacotes de 25k, mas parece que ele não decolou e ficou com alguns lançamentos de trilhos.

    

Answer 6

« Onde devo desenhar a linha entre o uso do apt-get e gem ao configurar um servidor para hospedar ruby on rails com passageiro + apache? Isso importa mesmo? Parece errado misturar sistemas de gerenciamento de pacotes ao considerar atualizações de software e assim por diante. »

Note que o APT (do qual o 'apt-get' faz parte) não é um gerenciador de pacotes, ele é um gerenciador de dependências. Isto é muito importante; o gerenciador de pacotes é DPKG.

Agora, a regra é que um conjunto de diretórios deve conter apenas um conjunto de pacotes gerenciados por um único gerenciador de pacotes, ou coisas muito ruins acontecerão (por exemplo, um pacote gerenciado por um pacote será parcialmente sobrescrito sem aviso por um pacote gerenciado por outro).

O RubyGem é um gerenciador de pacotes como o DPKG, ou como os downloaders EasyInstall CPAN ou Python do Perl, e eles nunca devem ser misturados com outros gerenciadores de pacotes, incluindo o DPKG.

« A maior vantagem que vejo em usar uma joia para a maioria das coisas é que posso ter mais de uma versão instalada de uma só vez. »

O DPKG não pode ter versões diferentes ou plataformas diferentes do mesmo pacote instalado é uma limitação muito grave e ruim, o que fez com que o Debian criaria soluções extremamente feias e ruins (codificando versão e plataforma no próprio nome do pacote). Infelizmente, aqueles que escolhem usar o DPKG têm que viver com essa limitação.

    

Answer 7

Caso não esteja claro na minha resposta anterior:

« Parece errado misturar sistemas de gerenciamento de pacotes »

É realmente errado misturá-los na mesma subárvore . Se você instalar dois sistemas de gerenciamento de pacotes (por exemplo, DPKG e RubyGems), dando-lhes subárvores diferentes, isso vai ficar bem. É por isso que '/ usr / local' é uma subárvore separada e '/ opt' é outra subárvore separada. O RubyGems, por padrão, usa '/ usr / local / lib / ruby', o que parece plausível para mim (e não entra em conflito com o DPKG, mas pode entrar em conflito com pacotes instalados manualmente).

« tem mais de uma versão instalada de uma só vez. »

Se isso for um requisito, use RubyGems em uma subárvore separada, como mencionado acima. DPKG como você descobriu simplesmente não pode fazê-lo de qualquer maneira decente. A comparação aqui é entre RubyGems e DPKG, não com o RPM, que nunca foi mencionado na sua pergunta ou na minha resposta anterior, mesmo que alguns Debianistas pareçam ter um complexo de inferioridade sobre o RPM.

Ter várias versões de uma biblioteca ou aplicativo é um recurso muito importante, especialmente para testes versus uso de produção e, especialmente, para aplicativos da Web, portanto, eu recomendaria RubyGems e não usaria debgems.org.

    

Answer 8

É provavelmente uma daquelas perguntas em que você veria 50/50 de divisão. Talvez você deva definir seus critérios com mais precisão para obter uma resposta útil.

Na minha experiência, todos os gerenciadores de pacotes baseados em * nix como ports, macports, rpms, dpkgs, etc. possuem inter-dependências bastante estranhas, e freqüentemente instalam coisas que você não quer ou não precisa para sua tarefa, ou não instale o que você precisa. Eu não vejo o mesmo padrão com gemas ou pacotes de CPAN.