Pessoal, Assunto complicado esse heim? Pra mim o slack é o melhor linux que tem devido a sua estabilidade e segurança. O problema está quando precisamos de uma pacote que não está na lista oficial. Temos que pegar o fonte, compilar e fazer alguns ajustes, ou ainda, pegar os pacotes pré-compilados em sies como linuxpackages. E sempre que preciso instalar um pacote como squid por exemplo, tenho que pegar o fonte e compilar. Isso vai cansando qualquer usuário com o tempo. Andei me perguntando sobre o uso do Debian devido a sua facilidade de instalação de pacotes através do apt-get. Complicado esse questionamento.
1 - O que poderíamos fazer é utilizar os builds do slackbuilds como base e nós mesmos criar os nossos caso não tenha. Creio que temos capacidade para fazer esse trabalho sem problema. 2- Poderíamos também pegar umas 3 ou 4 pessoas por software para ficarem responsáveis por ele e manter atualizado a cada versão. No site poderíamos disponibilizar o build, fonte e o pacote compilado tudo para download. 3 - Desenvolver um script para pegar esses pacotes tipo o slackpkg ( que baixa somente pacotes oficiais ) , ou fazer um negócio tão bem feito que poderíamos incorporar o nosso repositório com opção para download nele com apoio do tio Patrick Sérgio Abrantes []'s 2008/9/23 Psycho Mantys <[email protected]> > > Rodrigo Luiz wrote: > > 1 - Vamos empacotar *somente* builds do slackbuilds.org, ou iremos > > abrir algumas exceções? > > A idéia de utilizar os scripts do slackbuilds.org é justamente pra > > diminuir o nosso trabalho e tempo para analisar scripts. Além do mais, > > a equipe que aprova os scripts no site possuem muito mais competência > > que a gente. > > > > Os builds do SlackBuilds são mais fáceis. Pelo que eu vi, eles ja tem um > sistema de pacotes para baixar e criar o pacote. Com um pouco de script, > magia negra e POG, criamos um repositório que se cuide automaticamente. > Essa é uma boa idéia, mas ao meu ver, é trabalho de inicio. Inicio para > alguma coisa maior. > > > 1.1 - Caso mude apenas a versão do programa X, iremos empacotar mesmo > > que no site do SBo esteja na versão anterior? > > Vamos supor que acaba de sair o squid versão 3.0-stable10 e o script > > que tem no SBo é para o squid 3.0-stable9. Iremos empacotar > > independente do SBo atualizarem os builds, já que o changelog do > > software certamente não traz mudanças radicais, ou é melhor seguir > > fielmente o site? > > > > Ao meu ver, não precisa. Se sair uma versão mais nova de alguma coisa, > podemos simplesmente "avisar" a quem mantém o pacote que existe uma > versão mais nova, e pedir para ele atualizar o SlackBuild. > A não ser que o SlackBuilds.org tenha uma política de não atualizar os > pacotes. O que eu acho improvável(acho). Portanto, podemos pular essa > preocupação, acho. > > > 2 - Empacotar é algo muito serio. Quem irá empacotar? Quantas pessoas? > > Temos aqui talvez uma das perguntas cruciais. Quanto menor o número de > > pessoas que empacotam, maior o nosso controle e segurança, porém > > teremos mais trabalho para empacotar. E infelizmente não dá pra > > aceitar alguém que por exemplo entrou na lista agora e que não > > conhecemos para empacotar. Seria como dar a chave de sua casa para uma > > pessoa que você nunca viu. > > > > Sendo assim, poderíamos trabalhar na forma de elo de confiança. Por > > exemplo, o redhate sugeriu o supergrilo para ficar à frente do projeto > > (será que ele topa?). Neste caso, ele iria definir quem poderia > > empacotar os pacotes além dele. Depois de certo tempo, esses > > empacotadores poderiam indicar ao supergrilo outras pessoas. E assim > > por diante. É claro que esse número não pode tender ao infinito, > > teríamos que estabelecer um limite máximo. > > > > Isso não é problema se a gente usar os SlackBuilds do SlackBuilds.org. > Eles já são testados e aprovados, então e só fazer o que eu menciona no > item 1. Mas, se a gente criar um site para hospedar SlackBuilds, esse > seria um problema. > Mas poderíamos resolver de forma simples: Submetem os SlackBuilds para > um grupo de pessoas confiáveis e grande. Essas pessoas checam o > SlackBuild e, se esse for confiável, roda e gera o pacote. Sobe no site > o SlackBuild e o pacote. Isso distribui mais o trabalho e aceita > contribuições, mantendo a segurança. > > > 3 - Padrão para empacotar. > > 3.1 - Definir o ambiente em que os pacotes serão empacotados - > > Slackware instalado de forma full, sem nenhum pacote de terceiros > > instalado, exceto no caso do pacote a ser criado *precisar* de alguma > > lib que não venha por padrão no Slackware, e esta já tem que estar > > empacotada e disponibilizada no nosso site. > > > > Isso pode ser definido assim. Se esse pacote precisa de uma biblioteca > ou algo parecido especifico, faço antes um SlackBuild dessa dependência. > Ai vai recursivamente ;). > Se já tem o pacote na distro, então não precisa recompilar. Usa o pacote > da distro. Se você precisar de algo mais novo da distro, ai é que fica o > probrema. Essa parte e que precisa pensar uma solução e tem varios > caminhos. O pessoal do slackit deixa pacotes mais novos no site, mesmo > que a distro já tenha um pacote, por exemplo. > > > 3.2 - Iremos utilizar slack-required? > > > > Vão me xingar agora, mas eu acho legal usar a estrutura que o slapt-get > trabalha. Toda a estrutura do diretório install. Não e ruim de usar, da > mais organização e informação, e com o programa requiredbuilder > (http://www.stabellini.net/requiredbuilder.html) fica bem pratico e > fácil. E só colocar no script uma chamada ao requiredbuilder e pronto. > Ele faz o resto. > > > 4 - Quais pacotes? > > Tem que ser decidido também qual será o critério para escolher do que > > empacotar. Se iremos colocar sugestões pro povo dar, etc, já que > > empacotar tudo de uma vez só fica meio difícil. > > > > O que eu disse na sugestão 2. ;). > > > 5 - Outros serviços > > Além do serviço de empacotar, temos também todo um trabalho que > > envolve site e etc. E aí pode entrar a ajuda das outras pessoas. Toda > > ajuda é bem vinda. > > > > Isso é mui vero. Sou uma "anta do design" (alias, tive ate que procurar > no google como se escreve "design"...). O site é uma parte importante do > sistema, tem que ser bonito para ser atrativo, e também vai nos guiar em > nossos trabalhos. > > > > > --~--~---------~--~----~------------~-------~--~----~ GUS-BR - Grupo de Usuários de Slackware Brasil http://www.slackwarebrasil.org/ http://groups.google.com/group/slack-users-br Conheça o Novo Forum do GUS-BR na Under-Linux.Org em: http://under-linux.org/forums/slackware/ -~----------~----~----~----~------~----~------~--~---
