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
Lists: gentoo-perl: < Prev By Thread Next > < Prev By Date Next >
To: gentoo-perl@g.o
From: Michael Cummings <mcummings@g.o>
Subject: Re: Fwd: Réf. : Re: g-cpan ;)
Date: Thu, 12 May 2005 08:01:06 -0400
On Wednesday 11 May 2005 04:58 am, Elfyn McBratney wrote:
> /me waves @ new list :)
/me waves back ;)
> Exactly, this is a perfect reason to keep, and improve upon the notion of
> `g-cpan --upgrade`, imo. :)  Being able to respond to bug reports with a
> `g-cpan --upgrade whatever ..` and fix a user issue (come up quite few
> times in the month and a half that i've been on perl@, as Mike mentioned ;)
> makes all our bug-wrangling lives easier.
> Expanding on this a little, and now vdb has been mentioned ;), we could
> have, say, a --check-origin option to g-cpan - which would check for a
> tag/identifier in the ebuild in the vdb denoting that it was created by
> g-cpan - to ascertain whether or not the ebuild was installed via g-cpan
> (duh ;) or not .. not something that would be as useful now, but in time
> once such a thing is wide-spread .. lemme know if I'm way of base 'ere ;)

Actually, this was the idea behind having all of the g-cpan ebuilds (when an 
overlay is present) to be stored in $overlay/perl-gcpan - if it's in 
perl-gcpan, then its their problem so to speak.  For that matter, even if 
they don't have an overlay, when they emerge the temp file a copy of the 
ebuild is being plopped in /var/db/pkg/perl-gcpan/ anyway, so either way we 
have a means of identifying those ebuilds without any special tags (unless 
you twist my arm real nice, in which case I'll agree to anything :)

Also, fwiw, the upgrade functions got cleaned a little bit yesterday :) 

>   - check for the latest cpan version of foo;
>   - grab the latest versions of foo's dependencies (if any);
>   - write that out to a world/avail. file (a saved-state thing)
>   - use it on the next g-cpan run (upgrade if not within a set 'cache ttl'
done i think - not clear on the cache stuff (just groggy)

> With that (getting slightly adventurous) we could implement things like
> CPAN-dependency listings (a la `emerge -pvt dev-perl/Foo` - without having
> to actually make the ebuilds), --pretend (you know what that'd do ;),
> --sync (update metadata from CPAN, maybe even fetching the Xmodules.txt
> (tho'll do this every other day when said files are updated), etc.
> files and stashing them locally, ..

-pv works now. If they have an overlay and the ebuild was stored, even if they 
didn't emerge it last time it's still available to emerge -pv output ;) As 
for the syncing - cpan updates its metalist based on a time default (1 day i 
think is the generic), so i'm leary of this whole synching again thing...but 
I don't think I'm understanding the implications completely either :)

ok, on to the next email i didn't answer...


Michael Cummings   |    #gentoo-dev, #gentoo-perl
Gentoo Perl Dev    |    on 
pgpnUqAbAhe7I.pgp (PGP signature)
Fwd: Réf. : Re: g-cpan ;)
-- Michael Cummings
Re: Fwd: Réf. : Re: g-cpan ;)
-- Elfyn McBratney
Lists: gentoo-perl: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Fwd: Réf. : Re: g-cpan ;)
Next by thread:
Revision 9 : clean cpan_stub()
Previous by date:
Réf. : look'n'feel
Next by date:
Re: Réf. : look'n'feel

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.