OK, I'm going to cut this up a little, but to bring everyone into the chain 
for a discussion cab and I were having about g-cpan (or my responses) :)

>- What about the --upgrade ? I'm not sure it's a good idea (at least for
>now). It relys too much on user's behaviour imho, praying that he didn't
>delete/move his overlays/ebuilds. Maybe there could be another way using
>/var/db to find what we need. I think that for now beu's suggestion of a
>simple --list to get all ebuilds handled by g-cpan would be a better first
>step ;)

I'd kind of like to keep the upgrade (now that it's there). The idea behind it 
is if user installs module-foo-1 via g-cpan, they can't in the old system 
upgrade it without removing the ebuilds from their overlay. This gives them 
the ability to upgrade, as well as to tweak/update for upstream changes. Also 
means we can say "we don't support it, but use g-cpan to upgrade it" (beu 
knows what i'm talking about re: recent bug history)


>- would a special file dedicated to g-cpan be a good thing ? now that it's
>a standalone application, we maybe could have it to be a bit bigger. For
>example, this (these) files could allow us to store ebuild infos (what has
>already been generated, pathes, versions.. etc), or as small CPAN infos
>repository, by having an internal db of versions of every modules without
>having to call CPAN each time we launch g-cpan. a g-cpan --update command
>would update this mini-db, or we could force it on a regular basis, or add
>a check in g-cpan.

Not sure I follow (I think I do, but could you expand?)

>- Thinking about config and optional options, wouldn't a config file be an
>helpful thing ? let's say a /etc/g-cpan.conf, that would allow us to store
>default behaviour, delays between forced update, and such things..

or ~/.g-cpan.conf since we now support user calls :)

>smaller things :
>
>- a special sub for md5ing things ? ($md5 = md5-sum($file)). It would clean
>some lines ;)

as well as the whole scanning the tree parts :)
>
>- updating exit_usage ;p
yeah - thinking we might not want to remove the generated config for cpan, 
just tell them its there and they can fix it if they want better performance

>That's all for his hour
>Am i thinking too much ? :)
maybe :)




-------------------------------------------------------

-- 

-----o()o---------------------------------------------
Michael Cummings   |    #gentoo-dev, #gentoo-perl
Gentoo Perl Dev    |    on irc.freenode.net 
-----o()o---------------------------------------------