Gentoo Archives: gentoo-perl

From: Michael Cummings <mcummings@g.o>
To: Gentoo Perl <gentoo-perl@l.g.o>
Cc: Rendhalver <rendhalver@×××××××××.com>
Subject: [gentoo-perl] g-cpan : features/requests?
Date: Thu, 21 Jul 2005 09:39:43
OK folks, that time of the cycle again. If you have any requests or
features you'd like to see in the next release of g-cpan, please post
them here (prefer on list vs. offlist - better to get a discussion going
that way ;)

Here is what I am already working on, just to get the pot boiling:

* Dependencies - I'm ripping out the use of for this and instead
doing a parse of (if existing) Makefile.PL, Build.PL, and META.yml files
for relevant dep information, combining everything gleamed into a more
comprehensive list. The rationale is that this will allow us to better
track DEP/RDEP information than the current system, and remove the need
for a configured CPAN at one more step. My ultimate goal here is
twofold: no more interaction, and the ability to generate
transportable ebuilds. Currently the ebuild that is generated neglects
most DEP's, only listing those dependencies that aren't already
installed. Further, it has no version tracking for those DEP's, which
can be critical at times. 

* Better ${S} generation - Currently there is no check to make sure that
the downloaded file is also the name of the exploded directory. 9 times
out of 10 it is - but there's that one in 10 where it isn't, and I'd
like to see g-cpan handle this gracefully. (The more g-cpan can handle
gracefully, the less spurious requests we get via bugzilla for adding
module F00 because g-cpan couldn't handle it).

* DESCRIPTION - like, its not getting filled now, and I want it to be ;)

* MANIFESTS - currently not being generated, and with a semi restrictive
make.conf this is a problem since there is no MANIFEST to verify

* metadata.xml - I'd like to see g-cpan plop in a generic metadata file
indicating that this was an auto-generated ebuild, and what can and
can't be posted in bugzilla. Oddly, some people actually read these
before submitting bugs. Go figure :)

* (Downloaded) data files - OK, this may take a bit of explaining. Its
becoming apparent that there's a lot of (simple) data that we'd like to
be able to pull into g-cpan without hardcoding it directly into
g-cpan. My concept is to set up some space in the projects section,
including a data directory that g-cpan can pull update data files from.
These data files would consist of:

	* a list containing a mapping of ebuilds to upstream tarball names
(i.e., checking for MY_P and P differences so we don't generate an
ebuild via g-cpan because g-cpan doesn't recognize our dir name as the
upstream name - perl-PDF, glib-perl, and gtk2fu are examples). The side
effect of this is that we also wouldn't need to rely on lc'ing
everything to be sure its right - we'd have the direct mapping to begin

	* a list containing the current locations of cpan modules in portage.
Instead of hardcoding that array at the start of g-cpan with all
potential directories that we might someday use, it'd be nice if there
was just a list that could be sourced and easily updated that said
"these are the directories to consider for existing ebuilds" - also
means no rapid release of g-cpan just because we add a new category that
should be considered.

	* a list of the perl modules shipped with an install of perl (by
version). I know, sounds odd, but take PathTools for instance - this
provides File::Find and Cwd, and can get confusing if g-cpan doesn't
realize in the prior bullet that these are all the same thing. And if
the dep is for version 0 - why bother generating an ebuild for it?

	* Snapshots from cpan (the 02* and 03* files). Mostly because if we are
going to go to the effort of pushing data, I'd like to push it from a
common point.

	* MANIFEST of all the above files - The idea with the manifest is to
have an md5sum of everything (hey, I know, but its as good as anything
else, and this isn't for security purposes, its for file change
tracking) that is the first thing to be downloaded. Local files are then
compared with the <some.official.gentoo.location/data/*> files so that
we can determine what does and doesn't need to be downloaded.

* Logging - I'd like to be able to allow the user to enable (or not)
logging of all g-cpan activities. I'm also favoring that this is a
/var/logs/ log and not just a local log, but I'm open on this. Of
course, this brings up

* A configuration file (global and local) - thoughts on what should be
in this if it existed? Preferred cpan mirrors maybe? preferred timeout
settings for downloads; log settings; anything else?

One of my goals here is to eliminate the use of Let's be honest
- everything we use for in the g-cpan process is easily dup'd,
using tools that the user already has available in order to maintain
gentoo itself. Eliminating it eliminates a dependency on a precarious
external application and configuration. And with the future of
being removed in favor of CPANPLUS (which will mean we would need to be
able to account for both options in g-cpan for those boxes not
upgraded), I think it would save a lot of headaches down the road to
just nip it in the bud now and provide a gentoo friendly alternative
ahead of time.

I acknowledge that g-cpan can't be perfect - its just not that type of
world - but I'd like to be as painless as possible. Any suggestions,
thoughts, further recommendations, detraction's? I can always disagree,
but I won't know it if you don't say something ;)



Subject Author
Re: [gentoo-perl] g-cpan : features/requests? Antoine Raillon <antoine.raillon@××××××.net>