Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-perl
Navigation:
Lists: gentoo-perl: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-perl@g.o
From: Michael Cummings <mcummings@g.o>
Subject: Fwd: Réf. : Re: g-cpan ;)
Date: Tue, 10 May 2005 20:32:15 +0200
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---------------------------------------------
Attachment:
pgpBIz6ENvpb5.pgp (PGP signature)
Replies:
Re: Fwd: Réf. : Re: g-cpan ;)
-- Elfyn McBratney
Re: Fwd: Réf. : Re: g-cpan ;)
-- Antoine Raillon
Navigation:
Lists: gentoo-perl: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Test post - welcome :)
Next by thread:
Re: Fwd: Réf. : Re: g-cpan ;)
Previous by date:
Re: Test post - welcome :)
Next by date:
Re: Fwd: Réf. : Re: g-cpan ;)


Updated Jun 17, 2009

Summary: Archive of the gentoo-perl mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.