Eu sinceramente nao vejo razao para mudar o sistema de pacotes do slackware, ele faz td que eu preciso, sem complicacoes, quando nao tem um pacote para slackware, basta procurar nos repositorios existentes.. ou senao se cria um slackbuild, caso vc deseje um sistema que compile de acordo com as flags, alguem ae em cima diz ter feito algo, tem tb o slackports( http://slackports.sf.net), feito por brasileiros tb... existem varios projetos nesse sentido, seria muito melhor ajudar um ja existente a sair sempre criando.
no site da GUS-BR tem uma secao de projetos, onde o intuito eh postar todos os existentes! eu apoio a criacao de um cd com pacotes extra para o slackware... uma vez criei um topico[1] no forum da slackbr sobre isso, fiz ate uns uploads, mas nao dei continuidade [1]: http://www.slackbr.org/forum/viewtopic.php?search_id=2075474910&t=6054 precisando de algo, estou aki ;-) abs[']ss On 9/4/07, Maxwillian Miorim <[EMAIL PROTECTED]> wrote: > > > On 9/1/07, Marcos Henrique Esteves Barbosa > <[EMAIL PROTECTED]> wrote: > > > > Olá! > > Estou desenvolvendo um novo formato de pacotes para o Slackware (já > > que o novo sistema de inicialização não deu muito certo, espero ter > > mais sucesso com a criação de um novo formato de pacote). Ele não vai > > sair muito do que é atualmente, para se manter simples, mas serão > > acrescentadas coisas para tornar o pacote mais completo. A principal > > mudança será a inclusão no diretório install (que poderá mudar para um > > nome mais significativo, mas ainda não tive uma boa idéia) de vários > > arquivos, cada um contendo uma informação. Por exemplo: O arquivo arch > > conterá a arquitetura. Uma lista de possíveis aqruivos: > > - arch (arquitetura) > > - preinst.sh (script para ser executado antes da instalação) > > - posinst.sh > > - name (script para ser executado após a isntalação) > > - version (versão) > > - release (revisão) > > - category/classification (categoria em que o pacote se encaixa) > > - developer (nome e e-mail do desenvolvedor) > > - packager (nome e e-mail do empacotador) > > - description (descrição) > > - filelist (lista de arquivos. É realmente necessária?) > > - dependencies (pacotes necessários para funcionar. Incluindo os > > básicos, como glibc-solibs) > > - suggests (pacotes sugeridos que aumentam as funcionalidades) > > - source (localização do fonte na internet. Deve ser melhorado para > > talvez ter um arquivo para o endereço e outro para o arquivo ou talvez > > não precise, já que o local onde pegar o fonte estará no SlackBuild) > > - size (tamanho que o pacote ocupa após instalado. Pode ser dividido > > em um que contenha o tamanho compactado e outro o descompactado, ou só > > o tamanho quando descompactado, já que o compactado pode ser visto no > > próprio pacote) > > - license (tipo de licença) > > - hash (hash do pacote. Precisa ser visto como será implementado) > > - signature (assinatura) > > - url/page/website (página oficial do pacote) > > - summary (descrição em uma linha) > > Nesta lista eu tentei incluir todas as informações que eu achei útil, > > baseando a lista em um pacote RPM (briga Slackware X Red Hat a parte). > > Não inclui coisas como "build date" e "build host" por não achar que > > tivesse utilidade (se alguém souber a utilidade fale). > > Também haverá modificações no sistema de criação do pacote. Ainda > > existirá o SlackBuild (que é um ótimo sistema) mas haverá modificações > > tanto para dar maiores opções quanto para facilitar o uso. As mudanças > > principais no SlackBuild são: > > - Remoção dos arquivos temporários após o final da compilação (talvez > > inclua uma variável para escolha, mas acho improvável) > > - O pacote pronto será movido para o diretório onde está o SlackBuild > > - O SlackBuild procurará o arquivo fonte no diretório atual. Se não > > encontrar, baixará da Internet > > Também haverá mudanças no formato do repositório, mas ainda não pensei > > bem nisso. Só acho que talvez seja uma boa idéia fundir o repositório > > de fontes com o de pacotes, mais ou menos como é feito no repositório > > do slacky.eu (www.slacky.eu/repository), onde existe as categorias e > > dentro diretórios com pacotes que por sua vez tem os pacotes e um > > diretório src/ para os fontes. O que acham? > > PS.: Se isso andar bem, que sabe esteja sólido para incluir na próxima > > versão do Slackware???!!! > > Na verdade o sistema de pacotes do Slackware faz quase tudo que tu quer: > > - A arquitetura é especificada no nome do arquivo, logo é redundante > especificar esta informação em outro local. O mesmo vale para versão e > "build" (não conheço formato de pacotes que ofereça tal recurso). > - preinst.sh, postint.sh lembram muito os pacotes do Debian, eles já > existem nos pacotes .tgz > - filelist, que tal um tar -tfv pacote.tgz? com o tar e um pouco de > awk também pode calcular o tamanho do pacote depois de instalado > - hash e assinatura estão nos arquivos .md5 e .asc junto dos pacotes, > é só olhar nos CDs ou no FTP > - descritpion = slack-desc > - remoção dos arquivos temporários (mas não há opção de mantê-los) > > O que o teu sistema de pacotes teria de novo ao atual seria a > resolução de dependencias. Sinceramente, eu acredito que algo como > fazer um banco de dados bem simples com uma relação ao estilo "pacote > -> dependecia" é mais que suficiente, ai é só fazer um "wrapper" pro > installpkg/removepkg/upgradepkg... De repente é mais simples > customizar o slackpkg pra isso (se ele ja nao faz :) > > -- > Max > > > > -- Luiz Antonio Oliveira aka redhate Linux User #347508 aMSN: [EMAIL PROTECTED] Licq: 251384040 ------------------------------------------------ GUS-CE http://gus-ce.slackwarebrasil.org --~--~---------~--~----~------------~-------~--~----~ GUS-BR - Grupo de Usuários de Slackware Brasil http://www.slackwarebrasil.org/ http://groups.google.com/group/slack-users-br -~----------~----~----~----~------~----~------~--~---
