<br><br><div class="gmail_quote">2010/12/5 Alexei Znamensky <span dir="ltr"><<a href="mailto:russoz@gmail.com">russoz@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div><br></div><div>Eu procurei por Business::BR::Ids (que é módulo, mas que também é o nome =~ s/-/::/g do tar ball. Na hora, presumi que funcionaria isso.</div><div></div></div></blockquote></div>
<br><div>O negócio é que as distribuições (ou tarballs) como coleções de packages podem mudar à vontade do desenvolvedor (embora isto não aconteça muito na prática, mas que acontece, acontece). Mas só esta possibilidade cria um problema muito grande para mapear dependências de módulos (ou packages) para distribuições.</div>
<div><br></div><div>Pensando um pouco, o negócio é que as dependências dos packages em uma distribuição deviam incluir os packages da própria distribuição, algo assim:</div><div><br></div><div> Business::BR::CPF depende de Business::BR::Id (esteja ou não no mesmo pacote)</div>
<div><br></div><div>mas isto é um "can of worms" devido à dificuldade de descobir dependências olhando em código fonte Perl – é fácil encontrar "require M" e "use M", mas que tal</div><div><br>
</div><div> $M->require (com UNIVERSAL::require)</div><div> load($M) (com Module::load)</div><div> eval STRING </div><div><br></div><div>e muitas outras formas de fazer o "link" dinâmico entre módulos. E tem mais, alguns destes "statements" serão dependências reais e outros módulos que colaboram. Neste último caso, só análise semântica feita por um humano seria capaz em alguns casos de fazer uma decisão acertada a respeito.</div>
<div><br></div><div>Ok, desculpas pela intromissão e digressão. Deu vontade de falar potoca um pouco, já que apareço por aqui tão pouco. Continuem por favor. :-)</div><div><br></div><div>Adriano Ferreira </div>