Me cansei do SBopkg

Publicado por Slackjeff em 17/02/2020

[ Hits: 3.147 ]

Blog: https://slackjeff.com.br

 


Me cansei do SBopkg



Eu sou dos caras que gosta de poupar recursos e gosto de desenvolver meus próprios mecanismos, ou em nosso termo 'hacks', para fazer a manutenção do sistema. O Slackware na atualidade é um dos pioneiros nessa questão, você administra o sistema do seu jeito, cria os seus próprios hacks e pode brincar a vontade... não importando muito como é feito, se funciona, faz bem para você é o que vale.

A um bom tempo utilizo e sou mantenedor de alguns SlackBuilds do site slackbuilds.org, depois de muito lutar e muita gente me pedindo "canal no YouTube, pessoas pedindo review", acabei que caindo na tentação de usar o SBopkg. Eu falei para mim mesmo:

"É só por uns dias, vou aprender as principais funcionalidades bem e fazer o review da ferramenta e mostrar para as pessoas"

Basicamente era esse meu pensamento. Bom, se foram quase 3 anos usando essa ferramenta escrita em shell contando até hoje com 4921 linhas de código e mantido pelo Willy.

Para quem não sabe o SBopkg é uma ferramenta que automatiza a tarefa de compilação/instalação dos SlackBuilds, tem um sistema de busca, instalação, sincronização, atualização e remoção dos pacotes criados pelo slackbuilds. Não podemos esquecer do Queuefiles, uma mão na roda aonde você pode fazer o empilhamento das dependências. Fora outras funcionalidades interessantes para manter os seus Slackbuilds no seu sistema. Não é um software ruim, de longe isso. É muito bem estruturado e feito.

Porém como eu sou enjoado, xiita fi da mãe, acabei largando o sbopkg faz uns dias. Depois de 3 anos vendo essa ferramenta evoluir acabei que me enjoando dessa automatização toda. O motivo? Bom, simplesmente hoje ele não atende a minha realidade. Tudo começou quando eu dei um downgrade na minha internet de 30MB para uma internet a rádio de 500kbps dividido em 3 pessoas na casa. A realidade que eu faço o download do melhor link da internet em 30 à 50kbps, o que é horrível!

Por esse motivo acabei também largando o slackpkg, mas esse é assunto para outro artigo :)

Eu tinha recentemente comprado um netbook 32 bits veio de guarda por 100 reais, e fiz a velha instalação e pós instalação de sempre e nela incluso o sbopkg, quando fiz a sincronia das portas online para minha máquina demorou mais ou menos 30 minutos para concluir. Já me irritei com o tempo e taquei um "removepkg sbopkg" sem dó. Eu sei... eu não pensei muito, talvez iria me arrepender.

Depois disso voltei a fazer o processo todo manualmente como eu sempre fazia no slackbuilds que incluía links + terminal, e vi o quão nutella eu tinha ficado e perdido o domínio do sistema... os slackbuilds que tinha mais intimidade, sabia as suas dependências de cor e salteado acabaram se perdendo no abismo dos "queuefiles". Mas como? Me perguntei logo em seguida. Isso se deve a sempre o mesmo processo, no meu github.com/slackjeff tenho um repositório só com os queufiles que uso, então eu sempre baixava, adicionava em /var/lib/sbopkg/queues/programa.sqf, carregava no sbopkg e já era, era só deixar o mesmo fazer o resto.

Bom, tem muita gente curiosa em relação a como usar o slackbuilds! Eu tenho um vídeo no YouTube aonde ensino de forma completa como utilizar!
Bom, o meu lance é o seguinte, eu abro sempre um terminal com o browser links e acompanho o changelog do Slackbuilds com os softwares que eu tenho em minha máquina. Como utilizo poucos softwares do Slackbuilds eu acabo que tendo conhecimento de todos que estão em minha máquina! Então se no changelog aponta uma versão mais nova eu basicamente abro outro terminal com o links também, baixo os scripts, executo e atualizo! Após isso é feito o processo abaixo.

Depois dessa breve história vou te passar um hack que eu sempre utilizei antes dessa automatização toda de 4k de linhas. Normalmente muitos softwares possuem dependências, o slackbuilds mostras as dependências que o software precisa e se você não quiser por exemplo mais o SSR 'Simple screen recorder' as dependências do mesmo vão ficar no sistema correto? A solução é remover manualmente as mesmas. Normalmente eu faço um hack bem simples para remoção automática que consiste em 2 simples etapas.

Criar o diretório slackbuilds

Crio o diretório slackbuilds em /var/log/slackbuilds/ este diretório de logs vai ter todas as tracks dos softwares que foram compilados/instalados utilizando o slackbuilds, é adicionado manualmente após cada instalação. Vamos supor que estou compilando o SSR, ele depende do ffmpeg e no ffmpeg eu sempre ativo o x264. Então são duas dependências para instalar o ssr em si. O programa principal é o ssr, então após compilar o x264 e instalar o pacote eu faço:

# echo 'x264' > /var/log/slackbuilds/ssr

Passar o caminho sempre de /var/log/slackbuilds/ é chato... seria melhor usar uma variável + nome não? Então adicione no .bashrc localizado em /root/.bashrc a seguinte linha:

# echo 'slackbuilds=/var/log/slackbuilds' >> /root/.bashrc

Como isto você não precisa mais passar o caminho absoluto e sim a variável + nome do pacote.

# echo 'x264' > ${slackbuilds}/ssr

E assim você vai seguindo, instalando e adicionando no arquivo de track. Claro que é mais prático instalar tudo primeiro e depois jogar todas as deps no arquivo de track em uma buxada... É melhor que ficar fazendo um por um não é?

# echo 'ffmpeg' >> ${slackbuilds}/ssr
# echo 'ssr' >> {slackbuilds}/ssr
cat << EOF >> ${slackbuilds}/ssr
x264
ffmpeg
ssr
EOF


Uma nota! No arquivo de track você não precisa por em ordem as dependências... as mesmas serão utilizadas para fazer a remoção do software + deps e apenas isso.

Outra nota! Não preciso te falar que se ssr depende de ffmpeg, Y depende de ffmpeg, Z depende de ffmpeg e eu remover junto com o ssr por exemplo, Y e Z param de funcionar. Acho que isso é o básico e você já deve saber.

Hack no .bashrc

Agora o segundo passo que eu faço sempre é criar uma função no .bashrc do root chamada removeslackbuilds, essa função vai basicamente rodar o removepkg puxando o arquivo de track. Vá até seu .bashrc e adicione:

removeslackbuilds()
{
   local archive='/var/log/slackbuilds'
  
   if cat "${archive}/${1}" | xargs -n 1 removepkg; then
      # Removendo o arquivo de track tbm :)
      rm "${archive}/${1}"
   fi
}

Ou para os preguiçosos:

# cat << EOF >> /root/.bashrc
removeslackbuilds()
{
   local archive='/var/log/slackbuilds'
  
   if cat "${archive}/${1}" | xargs -n 1 removepkg; then
      # Removendo o arquivo de track tbm :)
      rm "${archive}/${1}"
   fi
}
EOF


Então sempre que eu preciso remover um software que foi pego do slackbuilds e tem dependências eu executo removeslackbuilds SOFTWARE.

Se o software não tem dependências eu simplesmente ignoro a etapa acima e faço no braço normalmente.

Outras dicas deste autor

Evite discussão desnecessária no VOL

Google Chrome no Slackware 14x

Como criar um ALIAS

Qual é a diferença entre Unix e Linux

Compilação de Kernel Personalizado + TXZ [Vídeo]

Leitura recomendada

Compiz no Debian com XFCE4, LXDE, Gnome2 ou MATE (Squeeze e Wheezy)

PHP + Apache + MySQL no Ubuntu 12.04 - Instalação rápida

Problema com som no Sony Vaio vpcea24fm - Ubuntu 10.04

USB no VirtualBox

Removendo o som de discagem do wvdial

  

Comentários
[1] Comentário enviado por Tio_do_Toldo em 23/02/2020 - 11:23h

Não existe motivo racional mais para deixar de usar um gerenciador automático de pacotes e dependências. E nem para deixar de incluí-lo em uma distribuição.

Qualquer carroça de computador de 2 décadas atrás suporta o irrisório espaço extra de HD que algumas dependências extras/desnecessárias ocupam em disco. E o gerenciador em si ocupa KBs de memória. Ridículo. "Ahhhh, mas é que compilando...". Compila o que quer por fora carai, dá pra fazer isso por fora do gerenciador automático. O absurdo é uma distribuição vir sem isso por default. Você reclamou aí da sua internet ter problema pra atualizar todos os repositórios, mas nesse caso dá pra baixar separadamente um script em específico do SlackBuild.

No Slackware se tem que buscar as coisas de terceiros, de servidores não oficiais. Tudo fica mal integrado no sistema, meio "colado" na gambiarra.



Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts