1 |
I'm going to respond to everything in here, in case new subscribers |
2 |
don't know who I am either :) |
3 |
|
4 |
Chris White wrote: |
5 |
> I'm Chris White, live in Northern California. Hobbies include Japanese * and |
6 |
> general excercise methods. |
7 |
> |
8 |
My polar opposite. Excellent. Pictures of me will attest to this. |
9 |
> 2) Are you considered sane? |
10 |
> |
11 |
> Depends on what I'm doing, but in general no. |
12 |
|
13 |
We work on Gentoo. 'nuff said about that. |
14 |
|
15 |
> 3) Why care about perl |
16 |
> |
17 |
> I started working on perl because I noticed quite a few jobs wanted perl |
18 |
> experience as a requirement. I decided to re-learn perl (I'd used it before |
19 |
> slightly) and realized afterwards how powerful the language was for my |
20 |
> general usage. I realized that perl in Gentoo was a bit lacking, so I |
21 |
> stepped in and started to help. |
22 |
> |
23 |
I was drafted by accident, then spent 3 years trying to keep the tree |
24 |
sane before completely losing it. Rather than go on vacation I took the |
25 |
cowards way out and quit. I regret that decision, and am trying to get |
26 |
myself back on track (this email a case in point). |
27 |
|
28 |
> 4) What can we expect in the future? |
29 |
> |
30 |
> Ok, this leads to the second part of my email. Consider this draft but it |
31 |
> somewhat outlines my thoughts on the current situation: |
32 |
> |
33 |
> 1) g-cpan.pl needs help |
34 |
> |
35 |
> I've noticed that quite a few bugs in bugzilla stem from g-cpan.pl issues. |
36 |
|
37 |
Before I threw in the towel, I was working on an update to g-cpan that I |
38 |
will be re-approaching. Already written was better parsing code for |
39 |
determining dependencies better. This won't help with bad bundles (try |
40 |
Bundle::Catalyst::Everything sometime if you don't believe me - I have a |
41 |
bug in on it, but the problem is that there is no BUNDLE FILE included! |
42 |
Go figure - no wonder g-cpan has problems with that one, so does cpan, |
43 |
cpanplus, and any other means you can think of besides reading the |
44 |
readme and manually installing everything)(and good luck there, another |
45 |
victim of not listing all of the real deps properly is that some of the |
46 |
packages don't install in any way other than manually). |
47 |
|
48 |
|
49 |
> 2) Modules need updating |
50 |
> |
51 |
> I'm sure mcummings has already shown this but: |
52 |
> http://dev.gentoo.org/~mcummings/perl_updates.html. While the script that |
53 |
> created this has some minor issues, it still holds that it represents the |
54 |
> fact that there are lots of packages that need bumping. |
55 |
|
56 |
This is fairly up to date, I think I ran it after my last cycle of |
57 |
updates last night. This is very similar to the pages I posted links to |
58 |
on here a while ago, though the code is much more smooth and quicker to |
59 |
produce output from. I think ultimately, in addition to updating a web |
60 |
page, it'd be nice to get this output to this mailing list periodically |
61 |
(say weekly). Maybe, wouldn't want you all to suffer from mail overload |
62 |
from this mailing list :) |
63 |
|
64 |
|
65 |
> 3) Collision protection needs work |
66 |
> |
67 |
> mcummings and myself have been talking about this for a bit. The plan seems |
68 |
> somewhat set, but we just need to figure out what's going on. |
69 |
|
70 |
I have a few thoughts on this subject, some will be a repeat for Chris |
71 |
but are for the edification of the rest of the list (those who care |
72 |
anyway :). One thought, leading at the moment, is to have to eclasses, |
73 |
the classic perl-module eclass, and a perl-app eclass which in turn |
74 |
inherits perl-module.eclass. With this split, we could create man pages |
75 |
in the -app version, and the -module version wouldn't (since why do you |
76 |
need man pages when you can perldoc a module?). The rational here is |
77 |
that 99% of the collision protect violations have to do with man pages |
78 |
for core vs ebuild module installs, so don't make install the man pages. |
79 |
This is the quick and easy solution for all, since we would then only |
80 |
need to go through and switch a few ebuilds to use perl-app.eclass and |
81 |
everything would be cheeky nice immediately. |
82 |
|
83 |
However, I had another thought (that Chris hasn't seen yet), and that's |
84 |
that pod docs are all man3 - an app that happens to use the perl eclass |
85 |
to build will still create its normal man1/5 man pages in addition to |
86 |
any man3 pods it might have - so why not just drop the man3 from the |
87 |
dev-lang/perl ebuild all together, since all it does is duplicate in man |
88 |
form what perldoc already gives us? Not as quick or clean as the |
89 |
previous thought, but it would be more efficient long term. I think. |
90 |
|
91 |
> 4) Perl minimal needs to be looked at |
92 |
> |
93 |
> Apparently perl with the minimal USE flag has caused some questions by various |
94 |
> users as to what it entails. If you have an idea on what USE="minimal" |
95 |
> emerge perl should do, feel free to comment here. |
96 |
|
97 |
Not my best moment of weakness. There was clamoring for a minimal perl |
98 |
install like "other distros use," ie one where all you get is the |
99 |
barebones perl compiler. So I did that. On the plus side, this allowed |
100 |
us a "build" version of perl, which got around a nasty, ancient bug in |
101 |
doing a complete stage1>2>3 ebuild (the infamous opnessl->perl loop if |
102 |
your use flags don't say -java - though why you would want java, I've |
103 |
never grokked...). Unfortunately, perl stripped down is fairly useless |
104 |
to a lot of people. I'd like to revisit this - maybe strip out those |
105 |
parts that we provide ebuilds for, leave the rest intact, a compromise |
106 |
between minimal and still having options that work. |
107 |
|
108 |
|
109 |
> 5) More documentation |
110 |
> |
111 |
> Documents should probably be setup for g-cpan usage, mod_perl setup, and what |
112 |
> mcummings has already posted. |
113 |
|
114 |
Definitely for mod_perl. g-cpan has, like, a man page, you know....let |
115 |
me know what's missing from it, i'd be happy to add it in :) |
116 |
|
117 |
|
118 |
> P.S., on the note of above, if what you've heard of is something you'd be |
119 |
> interested in doing on a regular basis, feel free to contact me with regards |
120 |
> to becomming a developer. |
121 |
|
122 |
I'd be interested in helping! :) |
123 |
|
124 |
OK, I think that qualifies as both an answer and an attempt to multiply |
125 |
the verbosity of this list in one fell swoop. W00t! |
126 |
|
127 |
-mike |
128 |
-- |
129 |
gentoo-perl@g.o mailing list |