Gentoo Archives: gentoo-perl

From: Michael Cummings <mcummings@g.o>
To: gentoo-perl@l.g.o
Subject: Re: [gentoo-perl] Introduction and Possible New Objectives
Date: Sat, 12 Nov 2005 00:34:18
Message-Id: 4375387E.5080000@gentoo.org
In Reply to: [gentoo-perl] Introduction and Possible New Objectives by Chris White
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