Só um comentário Slackpkg não resolve dependência :) Eu tmb acho que do jeito que o Slackware ta hj esta otimo. Este esquema de uns emails atrás de ter um cd com source bootável, a ideia é legal, mas pra que fazer isto se já existe o Gentoo :D
Eu acho muito bom o esquema de não resolver dependências, evita você ter que ter um exim4 instalado por que o openssh precisa de uma lib que colocaram como dependência o exim :) Você querer instalar o Squid e ele reclamar do seu apache (ta por isto eu não passei, mas o esquema do ssh sim :D) Bom, boa sorte :) []s Marcos Henrique Esteves Barbosa wrote: > Novamente muito obrigado pelas opiniões. Apesar de existirem muitas > informações no formato atual dos pacotes do Slackware, elas são > colocadas de forma meio "capenga". Por exemplo: O nome do arquivo não > é exatamente o melhor lugar para se colocar informações, isso por que > qualquer mudança no nome do arquivo (como acidentes ao renomear, > scripts incorretos para renomear arquivos, etc.) fazem com que a > informação se perca de forma a ser muito dificil de recuperar (um > exemplo é a arquitetura. Outro é a versão se a documentação não tiver > essas informações). Tudo fica disponivel de forma clara, tanto para um > usuário que queira ler ou um programa que queira usar a informação. É > bom deixar a parte dificil (no caso descobrir o tamanho com o awk) > para a ferramenta de criação do pacote, que fara isso uma vez. Se isso > não fosse feito seria necessário que cada programa (ou mesmo o > usuário) tivesse que escrever o código para buscar a informação. Isso > não é muito K.I.S.S. Quanto ao fato de ser uma tendencia a migração > para o formato RPM, eu discordo. Deve ter sido apenas uma época de > depressão do Patrick, porém mostra que ele não é feliz com o formato > de pacote atual. Quanto ao sistema de resolução de pacotes, eu não > gosto de sistemas de resolução de pacotes. Acho que deve haver > respeito para com o desenvolvedor do aplicativo. E é uma forma de > respeitar o programador fazendo com que o pacote dependa apenas dos > pacotes indicados como depêndencia na documentação (diferene do > Debian, que pega um pacote e divide em vários subpacotes. Se o > programador quisesse isso ele já teria feito) e os pacotes básicos, > como bibliotecas. Não quero um sistema de resolução de dependências > automático (e aposto que o Patrick também não quer, se não o slackpkg > teria entrado na árvore oficial), mas deve dar a informação precisa > para que um sistema de resolução de dependências (como slackpkg, > swaret, etc.) funcione. Sei que existe o hash e a assinatura, mas eles > estão separados, o que obriga a pessoa a lidar com três arquivos > (quatro, se contar o .dep). É consideravelmente mais fácil se ela > baixasse um arquivo que viesse com todas essas informações. Nessa > mesma teoria (quanto menos arquivos melhor) se baseia o SlackBuild, > que precisará apenas do arquivo do SlackBuild (sem slack-desc,slack- > required, etc.). Obrigado a todos que se canditaram a desenvolver. Sua > ajuda será muito bem-vinda quando tivermos a provação do Patrick para > tocar o projeto. Saudações a todos e até mais. > > On 4 set, 16:47, "Marcelo Andrade" <[EMAIL PROTECTED]> wrote: > >> Olá a todos! >> >> On 04/09/07, Marcos Henrique Esteves Barbosa >> >> <[EMAIL PROTECTED]> wrote: >> >>> - Não faço muita questão de um sistema de resolução de depêndencias >>> (que se fosse bem escrito, viria bem a calhar) mas no minimo uma lista >>> com TODOS os pacotes de que um aplicativo depende, até mesmo pacotes >>> básicos e já incluidos na distribuição padrão do Slackware. >>> >> O perigo que acho da resolução de dependência - por experiência de uso >> dos antigos RH 7.X - era baixar pacotes da internet e obter dependências >> cíclicas ou de downgrade. Numa palestra do Piter aqui em Belém, vi que >> a rigor, a rigor mesmo, os pacotes do Slackware não têm informação de >> dependência e que as próprias mensagens de erro devem ser bem claras >> sobre o que está faltando. Mas confesso que pode ser muito prático. O >> Netpkg do ZenWalk é justamente isso: junto com o .tgz do pacote, vai além >> do .asc e do .txt, um .dep com a lista dos nomes pacotes necessários >> separados >> por vírgulas >> >> >>> - Quanto a lembrar muito o formato RPM, sim é verdade. Eu olhei um >>> arquivo RPM para pegar idéia para os miniarquivos (arch, etc.). Mas o >>> pacote RPM tem coisas boas (e ruins também) que podem ser aproveitadas >>> (ou não). Não se esqueçam que o Patrick já levantou a possibilidade de >>> só usar o RPM como gerenciador de pacotes do Slackware. >>> >> Ahh... legal. Então desculpe-me Marcos Henrique, realmente eu não >> sou muito ligado no que acontece nas decisões do Slackware. Na >> verdade eu não sou muito fã do RedHat e do RPM justamente pelos >> problemas de dependências que tinha volta e meia quando usava, então >> olhei meio ressabiado com a idéia de mudar o sistema de pacotes pra >> ficar parecido com o RPM. Mas se de repente é uma tendência, acho >> que só seria o caso de analisarmos direito como fazer. >> >> >>> - Alguns comentários pessoais: Seria uma boa idéia se o CD das fontes >>> tivesse algum jeito de ser bootável, compilar e instalar os pacotes >>> como faz o Gentoo, porém sem baixar nada da Internet e junto um >>> sistema de compilação de pacotes facilitado, permitindo gerar a árvore >>> toda de pacotes para uma determinada arquitetura (por exemplo: Gerar >>> todos os pacotes para a arquitetura i686). >>> >> Essa eu acho uma idéia legal. Acho que o propósito do Emerde[1] é fazer >> algo assim, mas da vez que tentei usar ainda estava num estágio muito >> inicial. De qualquer forma, fica a idéia. Se eu puder ajudar em alguma >> coisa, >> estou à disposição. >> >> Atenciosamente. >> >> [1]http://emerde.freaknet.org/ >> >> -- >> MARCELO DE FREITAS ANDRADE >> | Computer Science Bachelor >> | Web Application Dev Specialist >> | Linux Certified Professional LPIC-1 >> > > > > > > --~--~---------~--~----~------------~-------~--~----~ GUS-BR - Grupo de Usuários de Slackware Brasil http://www.slackwarebrasil.org/ http://groups.google.com/group/slack-users-br -~----------~----~----~----~------~----~------~--~---
