/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 
CPAN.pm'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                                     http://beu.merseine.nu/
beu/irc.freenode.net                            http://dev.gentoo.org/~beu/
+------------O.o--------------------- http://dev.gentoo.org/~beu/pubkey.asc

PGP Key ID: 0x69DF17AD
PGP Key Fingerprint:
  DBD3 B756 ED58 B1B4 47B9  B3BD 8D41 E597 69DF 17AD