Gerenciamento de pacotes no Slackware Linux

fco

Uma das principais diferenças do Slackware em relação as outras distribuições Linux é seu sistema de gerenciamento de pacotes, que é bem peculiar. Este artigo visa abordar o "jeito Slackware de ser" neste assunto.

[ Hits: 34.498 ]

Por: Francisco Ambrozio em 10/06/2009 | Blog: http://franciscoambrozio.wordpress.com


Repositórios de terceiros



Até aqui falamos apenas do repositório oficial do Slackware. Mas de modo algum esta é a única opção para se obter pacotes para o Slackware, existem ainda os repositórios não-oficiais.

Um destes é o LinuxPackages. Trata-se de um repositório de pacotes, já compilados, contribuídos pela comunidade. Importante ressaltar que não se trata de um repositório endossado pelo Projeto Slackware Linux, mas ainda assim bastante utilizado. Muitos têm um pé atrás quanto a baixar e utilizar pacotes já compilados. Não vou tomar nenhum lado nesta questão, mas, em todo o caso, está aí uma opção.

Um outro repositório bastante extenso é o Slacky.eu, o site da comunidade italiana do Slackware. Além do fato de possuir um repositório bastante farto, acho interessante que não são fornecidos apenas os pacotes compilados, mas também os fontes para construir os pacotes por você mesmo.

Mas, sem dúvida, o mais destacado dos repositórios extras do Slackware é o Slackbuilds.org.

Slackbuilds.org - repositório de scripts para criação de pacotes

O Slackbuilds.org deveria ser o primeiro lugar onde um slacker deveria procurar um programa que não consta no repositório oficial. Isto porque em primeiro lugar, ele é mantido, dentre outros mantenedores, por alguns desenvolvedores do Slackware (mas ainda assim não é um repositório oficial) e segundo, porque ele acaba sendo uma forma de testar novos programas que podem vir a serem incluídos oficialmente na distro.

É importante mencionar que o Slackbuilds.org não se trata de um repositório de pacotes e, sim, de um repositório de SlackBuilds, que são scripts utilizados para criar pacotes a partir dos fontes.

Como utilizá-lo

Para instalar um programa através do Slackbuilds.org a primeira coisa (óbvia) a se fazer é achar o slackbuild. Você pode navegar através do link "Repository" ou então poupar um pouco de tempo e fazer uma busca.

Ao achar o programa que você desejava, você encontrará (além de uma breve descrição do programa) o link para o source do programa e um link para o slackbuild do mesmo.

Basta fazer o download dos dois. Na verdade o arquivo de slackbuild não contém o fonte (i.e., os fontes não são hospedados no servidor do Slackbuilds.org), mas disponibiliza um arquivo .info que contém o link para que se possa realizar o download. Logo, existem duas formas de baixar o fonte: através do link direto no site ou utilizando este arquivo .info. Vamos mostrar as duas formas, vou usar como exemplo a instalação do PostgreSQL.

1. Baixando o slackbuild e o fonte diretamente do site:

Buscando por PostgreSQL no repositório da versão 12.2 chegamos à seguinte página:
Segundo a versão corrente na época da elaboração deste artigo (a versão do PostgreSQL é a 8.3.7) o link para o slackbuild é:
E para para o fonte:
Depois de feito o download dos arquivos, passamos à extração do slackbuild:

tar vxf postgresql.tar.gz -C ~/slackbuilds

E depois movemos (ou copiamos) o fonte para o diretório do slackbuild.

mv postgresql-8.3.7.tar.bz2 ~/slackbuilds/postgresql

Feito isto vamos até o diretório onde os arquivos foram extraídos. Para aqueles que desejarem, o arquivo .SlackBuild pode ser alterado para realizar customizações, como ajustes de flags de compilação, por exemplo.

cd ~/slackbuilds/postgresql

Em seguida nos certificamos de que o script tem permissão de execução para podermos rodá-lo.

[ -x postgresql.SlackBuild ] || chmod +x postgresql.SlackBuild

Aqui vai uma nota que é bem peculiar ao programa que escolhermos. Se tentarmos rodar o slackbuild sem termos criado o grupo e usuário postgres, receberemos uma mensagem de erro como, por exemplo:

You must have a postgres group to run this script
  # groupadd -g 209 postgres

Não tem jeito, nunca confie em receitas simples. Mesmo seguindo tutoriais passo-a-passo, procure entender o que está fazendo (e não apenas repetir o que te mandam fazer) e leia as documentações disponíveis! ;)

Bom, toque dado, voltemos ao que importa! Neste momento só nos resta rodar o slackbuild (como root).

# ./postgresql.SlackBuild

Se nenhum erro ocorrer, um pacote será criado no diretório /tmp (este destino pode ser alterado no script, mas sempre é bom manter os padrões). Basta-nos instalá-lo:

# installpkg /tmp/postgresql-8.3.7-i486-1_SBo.tgz

2. Se tivéssemos baixado apenas o slackbuild (postgresql.tar.gz), o procedimento seria pouca coisa diferente.

Extrairíamos o slackbuild normalmente e iríamos até o diretório extraído:

tar vxf postgresql.tar.gz -C ~/slackbuilds
$ cd ~/slackbuilds/postgresql


Então utilizaríamos o comando source (ou .) para definirmos as variáveis contidas no arquivo .info.

. postgresql.info

E, por intermédio do wget, baixaríamos o fonte:

wget -c $DOWNLOAD

Aí é só seguir os demais passos descritos acima.

Conclusão

Enfim, o Slackware oferece uma abordagem diferente no que diz respeito a gerenciamento de pacotes. Mas, fica claro que este existe.

Como tudo nesta distro maravilhosa, as ferramentas são simples e poderosas. Se por um lado temos o inconveniente de não termos resolução de dependências automáticas, por outro lados temos o poder do controle sobre aquilo que realmente precisamos e queremos em nosso sistema.

Este artigo procurou abordar esta forma peculiar do Slackware gerenciar pacotes e o uso das ferramentas disponíveis.

É isto. :)

Grande abraço,
Xico.

Página anterior    

Páginas do artigo
   1. Pacotes no Slackware
   2. Mantendo-se atualizado
   3. Repositórios de terceiros
Outros artigos deste autor

Criando pacotes no Slackware Linux

Aos que estão começando...

Leitura recomendada

LaTeX, um poderoso diagramador de textos (parte 2)

Instalando Zabbix no CentOS 7

Instalando o Linux em HD SATA (SCSI)

Uma geral pela configuração pós-instalação do Slackware

XFCE 4.4 - Desktop alternativo a dupla KDE/Gnome

  
Comentários
[1] Comentário enviado por removido em 10/06/2009 - 18:37h

Cara, não consigo perceber razões pra apostar no Slack. Ter de permanecer atento ao changelog, resolver dependências manualmente é chato, trabalhoso e perigoso. Fico imaginando o qto isto propicia sistemas sem atualizações críticas de segurança. Acho que existe uma confusão entre complicação e eficiência, como se o mais complicado fosse sempre o mais enxuto, bem configurado e seguro.

PS: a estes dias abri um website, adicionei /phpmyadmin a URL, fui levado diretamente ao banco de dados com privilégios totais, abri uma tabela de usuários de um sistema de login muito mal feito, encontrei uma senha, digitei para root no ssh e ganhei acesso. O SO era Slackware, porcamente configurado (aceitando conexões ssh de qualquer um, admitindo login para root, vários serviços desnecessários em execução, pacotes mega-desatualizados et al..). Talvez alguns usuários encontrem bom proveito do uso da distribuição, mas não consigo ver nenhuma vantagem.

[2] Comentário enviado por demoncyber em 10/06/2009 - 19:42h

Lol parece q não foi lido o artigo inteiro bpiero =):

slackpg atualiza o sistema, você não precisa ficar vendo o changelog, eu somente leio o changlog que chega em meu e-mail minha máquina atualizada sem eu perceber.( uso o stable então são somente atualizações de segurança )

echo " 00 22 * * * slackpkg update && slackpkg upgrade-all " >> /etc/crontab

Lol agora porque encontraste um site com slackware configurado por um luser =), não siginifca q não existam tantos outros por ai com outras distros, que não tem uma entrada no crontab ou outro programa para atualizar o sistema.

Sobre a dependência, primeiro você tem q analizar que as dependências que você tem de resolver manualmente que possam ocorrer problemas são somente de programas não suportados as que são suportadas tem se o pacote pronto na arvore do slackware. Muitas pessoas pegam pacotes de respósitorios não oficias e instalam, ou mesmo pacote fornecidos pelos desenvolvedores de software isto não é referência, ambos podem ocasionar problemas, existem pessoas que desenvolvem pacotes para n programas para o slackware e ferramentas que resolvem as dependências para você (slapt-get, swarat, slackrock ...... ), mas usar é uma decisão pessoal, conheco pessoas que usam slackware e usam ferramentas para resolver as depedências e outras que são um pouco contras e ambas tem motivos que acho justos.

Bom acho que o argumento da segurança esta vago, como o reply a isto é construtivo resolvi responder. Não meu intuito aqui não é convencer você a usar.....

Para o autor foi um ótimo artigo parabéns

E fica a mensagem de que "Enquanto houver pessoas com o interesses similares e ideias sobre GNU/Linux parecidas, distribuições como Slackware continuaram existir"

[3] Comentário enviado por darkstarfire em 10/06/2009 - 20:03h

Concordo com demoncyber.


[4] Comentário enviado por fco em 10/06/2009 - 21:02h

Meu caro bpiero,

Acho que precisa exercitar um pouco mais sua interpretação de texto. Onde no artigo diz que "se deve apostar no Slack"? O objetivo foi mostrar uma peculiaridade desta distribuição para informar aqueles que usam ou pretendem usá-la.

Cabe a cada um tomar sua decisão. Este é o poder da escolha. Cada um usa o que se encaixa melhor à sua necessidade.

Algumas coisas que você diz são bem relativas. É chato resolver dependências manualmente, ok, quando são muitas eu até que concordo. Leva você a se perguntar se quer usar este programa mesmo, sempre há opções. No entanto, estamos livres para usar outra distro se determinado programa que realmente precisamos muito é mais fácil de instalar nesta. Aliás, este deve ser um dos critérios ao se escolher uma distribuição. Agora, generalizar, achar que nossa opinião é suprema e não aceitar a dos outros é estupidez, para não dizer outra coisa. :)

Verificar quais são as "novidades" em termos de segurança, pode até ser chato, mas é preciso. "Trabalhoso"? Depende. Você dá apt-get update && apt-get upgrade -y às cegas?

Agora, "perigoso"? Aonde?

Perigo é desinformação e o objetivo do artigo é justamente ir contra isto.

Quanto ao exemplo que você citou, não precisaria nem comentar, você diz tudo: "porcamente configurado". E certamente existem outros por aí, não só Slackware mas de outras distros também. Não vejo nenhuma relação entre o problema e o Slackware, ou melhor, que o fato de ser Slackware tenha contribuído para o desastre. Agora, algo me chamou a atenção - "pacotes mega-desatualizados". Ahan, então você lê os Changelogs? Ou é daqueles que não sabem a diferença entre um programa novo de um programa atualizado? :)

Enfim, é isto. :)

[5] Comentário enviado por paulorvojr em 10/06/2009 - 21:35h

Bom artigo, o que finaliza perfeitamente

"Como tudo nesta distro maravilhosa, as ferramentas são simples e poderosas. Se por um lado temos o inconveniente de não termos resolução de dependências automáticas, por outro lados temos o poder do controle sobre aquilo que realmente precisamos e queremos em nosso sistema. "

Administro desde red hats, centos, ubuntus, e slackwares, onde cada servidor e seus serviços uma distribuição é boa e outra é ruim.

Quero ver gente dando apt-get update && apt-get upgrade num servidor com 16gb de ram com oracle 10g r2 64bits rodando banco de dados de aplicação, a maioria nunca administra monstros desses.

64 bits não é brincadeira, o menor pacote mal feito, manda embora o sistema.

Problemas assim que o controle total do sistema é melhor, por isso slackware e red hat são os mais indicados

Pessoal não gosta muito de red hat, mas empresas adoram, é pago , licenciado gera recursos financeiros para ambas as partes, mas é tão estavél quanto slackware.


Missão crítica de servidores? Slackware na veia e Red Hat na veia.

[6] Comentário enviado por removido em 10/06/2009 - 23:24h

Parabéns Xicão,
o vol já estava com saudades dos seu artigos !!!!!!!!

[7] Comentário enviado por xerxeslins em 11/06/2009 - 00:28h

Que beleza de tutorial =]

Quando mais ajuda desse nível for divulgada, melhor!

Só uma observação para o bpiero: se o sistema que você acessou era falho, a culpa era do administrador e não do sistema. Além disso, mesmo sem gerenciador de pacotes, Slackware construiu sua fama sobre o que oferecia: estabilidade e controle. E só com isso, sem gerenciador de pacotes, exigindo conhecimento do usuário, ele é referência de distro. Mesmo sem gerenciador de pacotes o Slack é muito bom sim. Só não tem o objetivo principal de agradar quem quer facilidade.


[8] Comentário enviado por matheus.silva em 11/06/2009 - 12:32h

Primeiro,

Parabéns pelo artigo! Muito bem escrito!

Como o paulorvojr falou... "(...) Quero ver gente dando apt-get update && apt-get upgrade num servidor com 16gb de ram com oracle 10g r2 64bits rodando banco de dados de aplicação, a maioria nunca administra monstros desses (...)"

Realmente é uma loucura você rodar esses comandos ai.. ainda mais em um sistema 64 bits... Eu uso Debian mas concordo que para missões críticas.. slackware e red hat são muito melhores pelo controle que temos no sistema...

Porém o uso de ferramentas tal como o apt... é de escolha do usuário....

Exemplo: no Ubuntu com certeza eu uso apt,synaptic e afins para instalar as coisas e para atualizar o sistema.. pois o utilizo como desktop.. mas já tive experiências péssimas com esses comandos ai...

No Debian: eu particularmente só instalo as coisas com apt quando se é necessário as funções mais básicas do programa.. pois os pacotes .deb nos repositórios quase nunca trazem as funções necessárias... se você quer um squid com suporte a autenticação LDAP, ntlm e outras coisas mais... isso você, com certeza, não acha no repositório....
Instalo os pacotes, em sua grande maioria, pelos fontes dos mesmos... até porque preciso na maioria das vezes das versões mais atuais... coisas que o repositório também não traz....

Enfim,

O uso ou não dos gerenciadores é de escolha do usuário/administrador...

Cabe a ele deixar o sistema mais seguro ou enxuto....

Qualquer sistema é bom se você fizer as configurações necessárias.

[]'s

Matheus.

[9] Comentário enviado por ygorth em 11/06/2009 - 21:58h

Olá,

utilizo Slackware Gnu/Linux desde o 3.6 e mantenho até hoje no meu notebook este distribuição. Porém, já tive problemas serios com as ferramentas de atualizações de pacotes oferecidas pelo Slackware, como perda de arquivos de configurações importantes e falhas em serviços, e acabei perdendo a confiança nelas um ano atrás, hoje fico de olho nas atualizações as quais eu mesmo executo. Gosto de utilizar Slackware como desktop e servidores para soluções de segurança. O resto utilizo Red Hat, Debian e FreeBSD.

Vou testar a dica demoncyber, vamos ver o que rola.

Abraços!

[10] Comentário enviado por ---Anonymous--- em 12/06/2009 - 08:47h

Ei Tchico, no caso, se eu quiser atualizar o KDE 3.5 para 4... , eu poderia fazer por esse modo que voce explicou ou so baixando da internet mesmo???

[11] Comentário enviado por d4n1 em 12/06/2009 - 16:34h

Slackware sempre seguiu a filosófia KISS (Keep it simple stupid!).

O autor do artigo finalizou muito bem "...temos o poder do controle sobre aquilo que realmente precisamos e queremos em nosso sistema...", ou seja o usuário tem o poder!

O melhor sistema/distribuição é aquele que melhor se adequa a você e não o contrário.

Parabéns pelo artigo! Slack4ever!

[12] Comentário enviado por maran em 13/06/2009 - 03:27h

Belo trabalho, mais uma excelente contribuição para a comunidade.
Abraços, Xico

[13] Comentário enviado por fco em 13/06/2009 - 09:14h

A todos os que contribuíram com seus comentários, meu muito obrigado. :)

@ eu!noel - vem mais por aí. ;)

@ C# - atualizar o KDE não é uma coisa assim tão simples de se fazer. Não é apenas trocar os pacotes do KDE para a versão mais nova, tem muitos pacotes novos incluídos como dependência do novo KDE. Você tem 3 opções:

- a 1ª seria compilar todos os pacotes (KDE e dependências). Digo que será bem trabalhoso. :)

O KDE4 está sendo preparado para o Slack 13, logo, ele já está disponível na versão em desenvolvimento (-current), sendo assim, suas 2 outras opções seriam:

- atualizar o Slack para a versão -current. Mas aviso-o que é uma versão em desenvolvimento (testes). Podem ocorrer coisas "estranhas". Não é muito recomendada, a não ser que você seja um curioso ou um desenvovedor.

- esperar o lançamento do Slackware 13. Tá, é a opção mais chata (ninguém gosta de esperar :)), mas é a mais segura.

[14] Comentário enviado por antoniojbs em 30/11/2009 - 09:20h

Xico gostei muito do seu artigo comecei no mundo linux já com slack muitos não recomendavam disseram que era muito chato e que realmente ruim e disso pra pior.
Eu simplesmente esnobei já que eu era professor de informatica e tinha que entrar nesse novo mundo, como eu tinha lido bastante sobre cada distro continuei achando que slack iria me proporcionar um maior entendimento sobre linux já tudo era feito realmente na unha, e com isso já faz 3 anos que uso e se fosse hoje que eu tivesse que tomar minha decisão teria escolhido ele novamente.

É como eu sempre dizia pra os meus alunos "não é o sistema que lhe escolhe,não é ele que se instala em sua maquina e se administra sozinho você é quem o escolhe e você que tem que saber corrigir e configurar então pense em todos o pros e contras e principalmente não se torne um xiita de uma distro e sim do software livre".

Eu estou satisfeito com a minha opção, aprendo cada vez mais com slackware e pretendo continuar.
Outra coisa comunidade é isso que me deixa mais orgulhoso de todos vocês essa discursão sobre tal distro e sobre outra isso é o que faz a opinião de todos parabéns e cada um tem a sua opinião,essa é a minha abraços a todos.......

[15] Comentário enviado por Gabriel_Silva em 11/12/2009 - 19:21h

Putz.

[16] Comentário enviado por FromHell em 20/04/2010 - 16:07h

Cara muito obrigado por ter dado essa explanado sobre esse assunto q eh meio complicado mesmo pro lado do Slack. :D

[17] Comentário enviado por removido em 18/01/2011 - 19:05h

Parabéns Xico.
Seu trabalho continua atual.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts