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 -~----------~----~----~----~------~----~------~--~---
