Am Samstag, 19. August 2006 04:11 schrieb Michael Cummings:
> Ciaran McCreesh wrote:
> > On Fri, 18 Aug 2006 08:44:04 -0700 Donnie Berkholz
> >
> > <[EMAIL PROTECTED]> wrote:
> > | What would be more interesting is something like
> > | app-portage/g-cpan for various themes sites. This way, individual
> > | themes wouldn't need to get packaged and maintained.
> >
> > If anyone's looking to experiment with this kind of thing...
> > Paludis supports multiple repository formats. We're already
> > supporting CRAN, and we might do CPAN,

> really? i thought you told me in irc we weren't worth it or something
> like that...honestly not trying to troll or incite flame, you gather
> enough of that, but last we spoke about incorporating g-cpan like
> functionality into paludis on irc, it wasn't worth your time (choice
> expletives were used). from the gist of that conversation, paludis
> was not up to this job if the repository didn't fit some rather
> strict guidelines.
Actually, the conversation was more like:

 ciaran) What do we do next? CPAN? CTAN?
 kugelfang) let's ask mcummings for CPAN help. The deps can't be easily
            resolved iirc.
 mcummings) no other way, meta.yml isn't always there, and even
            g-cpan.pl needs several runs, and might even get the deps
            not correctly.
 ciaran) screw it then.
 kugelfang) CTAN? no deps at all.
 ciaran) screw it.

>From my POV those "screw it" were related to 'what do we do next', and 
not CPAN. Especially as CPAN wasn't the only option in consideration.

In regard to the to the 'strict guidelines' and 'paludis not up to the 
job'. We _could_ implement it, but none of the possible implementations 
is really elegant. We considered these possibilites:
* using an external repo, that autogenerates the dep information _after
  downloading all of CPAN_. (yes, that would be necessary)
* g-cpan mode of autogenerating the builds, where the distfiles need to 
be downloaded recursively at dep-resolution time.

Just to get the facts straight.

Danny
-- 
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project

-- 
gentoo-dev@gentoo.org mailing list

Reply via email to