http://www.linuxpackages.net/howto.php?page=perfect-package&title=Perfect+Package
Você tem que cuidar da compatibilidade com versões antigas. E, se algum dia o Patrick decidir resolver dependências nos tgz's uma solução muito boa (e em funcionamento no Zenwalk) são o slack-suggest e o slack-required. Vide a parte de opcionais do artigo acima. "arch", "version" e "release" são simples informações contidas no nome do pacote. Se você tem um pcaote cujo nome está corrompido talvez não seja boa idéia instalar ele; A retundância de scripts é um problema. Em se tratando de binários, faz sentido esperar que, após a instalação, um script pra criar usuários, criar bases de dados e adicionar configurações default seja suficiente. Listar pacotes não eve ser responsabilidade do pacote, mas do pkgtool. Tem outras coisas, mas não sou tão espírito de porco pra ficar só criticando, :D Ao invés de começar do zero, por que vc não pega os fontes do pkgtool, dá uma guaribada... ou mesmo trabalha ativamente em uma ferramenta APT-like dessas que tem pra slackware; o slackpkg tem plena compatibilidade com o pkgtool (de fato, responsabilidades diferentes), e com seu trabalho ele pode verificar se o pacote tem aquelas informações extra que os caras do linuxpackages sugerem; o slapt-get (bom... ele tava lah, eu uso ateh hj, :D) vem com a resolução de dependência implementada, mas desativada por padrão, pois os pacotes oficiais não oferecem suporte a resolução de dependência; Algo legal seria a sua sugestão de se adicionar informações acerca da categoria, os .deb e os .rpm já fazem isso, e a pasta install não explodiria se incluíssemos um txt nos moldes do slack-required. Espaço para expansão existe. O que não tem muito futuro é quebar 14 anos de padrão. 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???!!! >> --~--~---------~--~----~------------~-------~--~----~ GUS-BR - Grupo de Usuários de Slackware Brasil http://www.slackwarebrasil.org/ http://groups.google.com/group/slack-users-br -~----------~----~----~----~------~----~------~--~---
