On Wed, Apr 18, 2012 at 2:11 PM, Mrk3004 <[email protected]> wrote: > Acho que você não compreendeu muito bem a minha perspectiva de difícil e > trabalhoso. > > Por que é fácil? Porque não importa a forma ou que linguagem vá fazer, as > funções, comandos, variáveis que serão utilizadas na elaboração desse > gerenciador, todo programador já está careca de saber, você não tem que > criar nada de realmente novo, só precisa "organizar" os dados que já existem > (em sua mente). É como um quarto bagunçado que você tem que arrumar, isso é > trabalhoso, seria difícil se você tivesse que construir os móveis.
Bem longe disso. Um sistema de gerenciamento de pacotes de verdade inclui muito mais, ainda mais se tu descer para o lado da especificação das propriedades do pacote (ex: dependências, o que ele oferece, conflitos). Para fazer um sistema de gerenciamento completo tu tem que "construir" os móveis ou amontoar hacks em cima de hacks. > Difícil mesmo foi começar o projeto Wine, criar o primeiro Kernel, os > primeiros drivers para dispositivos multimídia, um tradutor de instruções de > máquina (assembly). > > Criar um simples gerenciador de pacotes? Isso é fácil... É mesmo? Estamos falando de um gerenciamento de verdade ou o teu conceito é um script que baixa uma duzia de tarballs, compila tudo, joga num outro tarball e extrai em algum lugar? Ou um script que baixa uma lista de pacotes e instala estes pacotes em uma determinada ordem? A forma que tu subestima a complexidade e os requisitos dos sistemas de gerenciamento de pacotes existentes (como o dpkg e o rpm) e a tua "comparação de maçãs com laranjas" não encorajam uma discussão muito produtiva... > Eu já comecei a fazer um sistema parecido com o gerenciamento de pacotes do > debian, que funcionava em conjunto com meu ftp e um aplicativo escrito em > python+gtk, mas ele precisava de um mantenedor que atualizasse os pacotes no > ftp para que tudo se tornasse realmente melhor, porque eu tendo que > atualizar tudo, acabava se tornando mais chato e demorado, pois não queria > utilizar o velho padrão de dados de repositórios do Slackware, pois nesses > seria difícil manter uma checagem de dependência segura e funcional. E > também com o tempo fui percebendo que não precisava disso no Slackware, era > só um vício que trazia de outras distribuições. Passei a utilizar algumas > funções desse mesmo programa para em vez de gerenciar dependências, > gerenciar versões, pois gosto de estar sempre atualizado com as ultimas libs > disponível. Agora ele atua como um daemon que de tempos em tempos checa a > url do site oficial do pacote e verifica se há alguma nova versão do mesmo, > se houver eu sou avisado com uma notificação na área de trabalho e também um > e-mail caso eu não esteja aqui, assim eu posso manualmente baixar e compilar > a nova versão. Isso é útil para mim, porque uso meu sistema apenas para fins > pessoais e tenho tempo para fazer essas compilações, mas pode ser totalmente > inútil para quem usa para outros fins. Ok, tu fez um script que lê um arquivo de configurações e faz o download de vários arquivos para instalar. Isso realmente é simples. E como o teu gerenciamento de pacotes lidava com múltiplas versões da mesma lib (ex: libpng 1.2, libpng 1.4 e libpng 1.5)? Pacotes conflitantes porque oferecem a mesma coisa (ex; pacotes A e B oferecem a libab.so)? Como tu sabia quais pacotes tinham bibliotecas com determinados símbolos (é assim que os RPM modernos constroem as relações de dependência)? Que tal usar mútliplas arquiteturas, como i?86/x86_64/x32 ou os zilhões de arm, como propõe a especificação do multilib no dpkg? E a eterna questão da resolução de dependências, como que faz com o pacote C que depende de B e B depende de A, mas A conflita com C? A coisa vai muito além de um gerenciador de downloads glorificado. Seria uma perda de tempo, mas tu poderia querer rebater cada uma das questões que eu levantei; só não esquece que tu tem que ter uma visão bem ampla na hora de fazer isso -- as pessoas por trás destes projetos (dpkg, rpm) vem trabalhando há quase 20 anos nisso e muitos já trabalhavam em similares de outros SOs antes, tem que ter um motivo para eles não terem escrito o gerenciador de pacotes perfeito até agora, não acha? > Eu acho que tudo vai do perfil do usuário, se você acha que estamos um > passo atrás de outras distros, e prefere o gerenciador de pacotes dessas, > você pode migrar. Eu faria isso se as dependências fosse um problema para > mim. Linux não deixa de ser Linux, não vejo porque não migrar. E qual o problema de alguém querer implementar um sistema de gerenciamento de pacotes melhor, implementar no "core" da distro? Se tu não gosta de um sistema destes, simplesmente não usa, continua baixando as coisas com slackpkg e/ou wget+installpkg. Esse pensamento de "se não tá satisfeito, muda" é meio retardado. Por que não podemos tentar melhorar ao invés de ficar pulando de distro para distro? A propósito, eu acho no mínimo irônico que tu abra uma thread dizendo que não consegue compilar um programa por algo que tu fez de errado na hora que tu gerenciava a instalação dos teus programas e depois dizer que as dependências não são problema para ti. ;) -- GUS-BR - Grupo de Usuários de Slackware Brasil http://www.slackwarebrasil.org/ http://groups.google.com/group/slack-users-br Antes de perguntar: http://www.istf.com.br/perguntas/ Para sair da lista envie um e-mail para: [email protected]
