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
Message-Id: 20050721053938.6f3b467a@sys947.dtic.mil
1 OK folks, that time of the cycle again. If you have any requests or
2 features you'd like to see in the next release of g-cpan, please post
3 them here (prefer on list vs. offlist - better to get a discussion going
4 that way ;)
5
6 Here is what I am already working on, just to get the pot boiling:
7
8 * Dependencies - I'm ripping out the use of CPAN.pm for this and instead
9 doing a parse of (if existing) Makefile.PL, Build.PL, and META.yml files
10 for relevant dep information, combining everything gleamed into a more
11 comprehensive list. The rationale is that this will allow us to better
12 track DEP/RDEP information than the current system, and remove the need
13 for a configured CPAN at one more step. My ultimate goal here is
14 twofold: no more CPAN.pm interaction, and the ability to generate
15 transportable ebuilds. Currently the ebuild that is generated neglects
16 most DEP's, only listing those dependencies that aren't already
17 installed. Further, it has no version tracking for those DEP's, which
18 can be critical at times.
19
20 * Better ${S} generation - Currently there is no check to make sure that
21 the downloaded file is also the name of the exploded directory. 9 times
22 out of 10 it is - but there's that one in 10 where it isn't, and I'd
23 like to see g-cpan handle this gracefully. (The more g-cpan can handle
24 gracefully, the less spurious requests we get via bugzilla for adding
25 module F00 because g-cpan couldn't handle it).
26
27 * DESCRIPTION - like, its not getting filled now, and I want it to be ;)
28
29 * MANIFESTS - currently not being generated, and with a semi restrictive
30 make.conf this is a problem since there is no MANIFEST to verify
31 against.
32
33 * metadata.xml - I'd like to see g-cpan plop in a generic metadata file
34 indicating that this was an auto-generated ebuild, and what can and
35 can't be posted in bugzilla. Oddly, some people actually read these
36 before submitting bugs. Go figure :)
37
38 * (Downloaded) data files - OK, this may take a bit of explaining. Its
39 becoming apparent that there's a lot of (simple) data that we'd like to
40 be able to pull into g-cpan without hardcoding it directly into
41 g-cpan. My concept is to set up some space in the projects section,
42 including a data directory that g-cpan can pull update data files from.
43 These data files would consist of:
44
45 * a list containing a mapping of ebuilds to upstream tarball names
46 (i.e., checking for MY_P and P differences so we don't generate an
47 ebuild via g-cpan because g-cpan doesn't recognize our dir name as the
48 upstream name - perl-PDF, glib-perl, and gtk2fu are examples). The side
49 effect of this is that we also wouldn't need to rely on lc'ing
50 everything to be sure its right - we'd have the direct mapping to begin
51 with.
52
53 * a list containing the current locations of cpan modules in portage.
54 Instead of hardcoding that array at the start of g-cpan with all
55 potential directories that we might someday use, it'd be nice if there
56 was just a list that could be sourced and easily updated that said
57 "these are the directories to consider for existing ebuilds" - also
58 means no rapid release of g-cpan just because we add a new category that
59 should be considered.
60
61 * a list of the perl modules shipped with an install of perl (by
62 version). I know, sounds odd, but take PathTools for instance - this
63 provides File::Find and Cwd, and can get confusing if g-cpan doesn't
64 realize in the prior bullet that these are all the same thing. And if
65 the dep is for version 0 - why bother generating an ebuild for it?
66
67 * Snapshots from cpan (the 02* and 03* files). Mostly because if we are
68 going to go to the effort of pushing data, I'd like to push it from a
69 common point.
70
71 * MANIFEST of all the above files - The idea with the manifest is to
72 have an md5sum of everything (hey, I know, but its as good as anything
73 else, and this isn't for security purposes, its for file change
74 tracking) that is the first thing to be downloaded. Local files are then
75 compared with the <some.official.gentoo.location/data/*> files so that
76 we can determine what does and doesn't need to be downloaded.
77
78
79 * Logging - I'd like to be able to allow the user to enable (or not)
80 logging of all g-cpan activities. I'm also favoring that this is a
81 /var/logs/ log and not just a local log, but I'm open on this. Of
82 course, this brings up
83
84 * A configuration file (global and local) - thoughts on what should be
85 in this if it existed? Preferred cpan mirrors maybe? preferred timeout
86 settings for downloads; log settings; anything else?
87
88 One of my goals here is to eliminate the use of CPAN.pm. Let's be honest
89 - everything we use CPAN.pm for in the g-cpan process is easily dup'd,
90 using tools that the user already has available in order to maintain
91 gentoo itself. Eliminating it eliminates a dependency on a precarious
92 external application and configuration. And with the future of CPAN.pm
93 being removed in favor of CPANPLUS (which will mean we would need to be
94 able to account for both options in g-cpan for those boxes not
95 upgraded), I think it would save a lot of headaches down the road to
96 just nip it in the bud now and provide a gentoo friendly alternative
97 ahead of time.
98
99 I acknowledge that g-cpan can't be perfect - its just not that type of
100 world - but I'd like to be as painless as possible. Any suggestions,
101 thoughts, further recommendations, detraction's? I can always disagree,
102 but I won't know it if you don't say something ;)
103
104 -mike

Replies

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