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 |