A idéia não é ruim, mas a solução é bem mais fácil.
Se sempre tem q pegar o fonte do squid e compilar, pq não gastar um
pouco a mais de tempo e criar um .tgz! Assim vc teria esse trabalho
apenas 1 vez.
Mas enfim, vamos ver o que a lista acha e se precisar, estou dentro.
Abraços
Sérgio Abrantes Junior escreveu:
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.
>
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/
-~----------~----~----~----~------~----~------~--~---
|
