Gentoo Archives: gentoo-perl

From: Elfyn McBratney <beu@g.o>
To: gentoo-perl@l.g.o
Subject: Re: [gentoo-perl] Fwd: Réf. : Re: g-cpan ;)
Date: Wed, 11 May 2005 08:58:30
Message-Id: 200505110958.27971@zippy.emcb.local
In Reply to: [gentoo-perl] Fwd: Réf. : Re: g-cpan ;) by Michael Cummings
/me waves @ new list :)

On Tuesday 10 May 2005 19:32, Michael Cummings wrote:
> 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)
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 ;)
> >- 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?)
gcpan-world, anyone ? :) Like the --check-origin idea above, with the metadata cab mentioned (installed cpv (category, package and version) next available cpv - the upgrade option, etc.), stored somewhere for later inspection, etc. Thinking about this some (probably duplicating parts or all of what cab was thinking ;), we could do the following on a new install/upgrade of an existing g-cpan'd ebuild: - 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' 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, .. </muse> :P
> >- 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 :)
Oooh, +1 :D
> >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 :)
This is all sounding cool, be is excited. :) Best, Elfyn -- Elfyn McBratney beu/ +------------O.o--------------------- PGP Key ID: 0x69DF17AD PGP Key Fingerprint: DBD3 B756 ED58 B1B4 47B9 B3BD 8D41 E597 69DF 17AD


Subject Author
Re: [gentoo-perl] Fwd: Réf. : Re: g-cpan ;) Michael Cummings <mcummings@g.o>