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
In Reply to: [gentoo-perl] Introduction and Possible New Objectives by Chris White
I'm going to respond to everything in here, in case new subscribers 
don't know who I am either :)

Chris White wrote:
> I'm Chris White, live in Northern California. Hobbies include Japanese * and > general excercise methods. >
My polar opposite. Excellent. Pictures of me will attest to this.
> 2) Are you considered sane? > > Depends on what I'm doing, but in general no.
We work on Gentoo. 'nuff said about that.
> 3) Why care about perl > > I started working on perl because I noticed quite a few jobs wanted perl > experience as a requirement. I decided to re-learn perl (I'd used it before > slightly) and realized afterwards how powerful the language was for my > general usage. I realized that perl in Gentoo was a bit lacking, so I > stepped in and started to help. >
I was drafted by accident, then spent 3 years trying to keep the tree sane before completely losing it. Rather than go on vacation I took the cowards way out and quit. I regret that decision, and am trying to get myself back on track (this email a case in point).
> 4) What can we expect in the future? > > Ok, this leads to the second part of my email. Consider this draft but it > somewhat outlines my thoughts on the current situation: > > 1) needs help > > I've noticed that quite a few bugs in bugzilla stem from issues.
Before I threw in the towel, I was working on an update to g-cpan that I will be re-approaching. Already written was better parsing code for determining dependencies better. This won't help with bad bundles (try Bundle::Catalyst::Everything sometime if you don't believe me - I have a bug in on it, but the problem is that there is no BUNDLE FILE included! Go figure - no wonder g-cpan has problems with that one, so does cpan, cpanplus, and any other means you can think of besides reading the readme and manually installing everything)(and good luck there, another victim of not listing all of the real deps properly is that some of the packages don't install in any way other than manually).
> 2) Modules need updating > > I'm sure mcummings has already shown this but: > While the script that > created this has some minor issues, it still holds that it represents the > fact that there are lots of packages that need bumping.
This is fairly up to date, I think I ran it after my last cycle of updates last night. This is very similar to the pages I posted links to on here a while ago, though the code is much more smooth and quicker to produce output from. I think ultimately, in addition to updating a web page, it'd be nice to get this output to this mailing list periodically (say weekly). Maybe, wouldn't want you all to suffer from mail overload from this mailing list :)
> 3) Collision protection needs work > > mcummings and myself have been talking about this for a bit. The plan seems > somewhat set, but we just need to figure out what's going on.
I have a few thoughts on this subject, some will be a repeat for Chris but are for the edification of the rest of the list (those who care anyway :). One thought, leading at the moment, is to have to eclasses, the classic perl-module eclass, and a perl-app eclass which in turn inherits perl-module.eclass. With this split, we could create man pages in the -app version, and the -module version wouldn't (since why do you need man pages when you can perldoc a module?). The rational here is that 99% of the collision protect violations have to do with man pages for core vs ebuild module installs, so don't make install the man pages. This is the quick and easy solution for all, since we would then only need to go through and switch a few ebuilds to use perl-app.eclass and everything would be cheeky nice immediately. However, I had another thought (that Chris hasn't seen yet), and that's that pod docs are all man3 - an app that happens to use the perl eclass to build will still create its normal man1/5 man pages in addition to any man3 pods it might have - so why not just drop the man3 from the dev-lang/perl ebuild all together, since all it does is duplicate in man form what perldoc already gives us? Not as quick or clean as the previous thought, but it would be more efficient long term. I think.
> 4) Perl minimal needs to be looked at > > Apparently perl with the minimal USE flag has caused some questions by various > users as to what it entails. If you have an idea on what USE="minimal" > emerge perl should do, feel free to comment here.
Not my best moment of weakness. There was clamoring for a minimal perl install like "other distros use," ie one where all you get is the barebones perl compiler. So I did that. On the plus side, this allowed us a "build" version of perl, which got around a nasty, ancient bug in doing a complete stage1>2>3 ebuild (the infamous opnessl->perl loop if your use flags don't say -java - though why you would want java, I've never grokked...). Unfortunately, perl stripped down is fairly useless to a lot of people. I'd like to revisit this - maybe strip out those parts that we provide ebuilds for, leave the rest intact, a compromise between minimal and still having options that work.
> 5) More documentation > > Documents should probably be setup for g-cpan usage, mod_perl setup, and what > mcummings has already posted.
Definitely for mod_perl. g-cpan has, like, a man page, you know....let me know what's missing from it, i'd be happy to add it in :)
> P.S., on the note of above, if what you've heard of is something you'd be > interested in doing on a regular basis, feel free to contact me with regards > to becomming a developer.
I'd be interested in helping! :) OK, I think that qualifies as both an answer and an attempt to multiply the verbosity of this list in one fell swoop. W00t! -mike -- gentoo-perl@g.o mailing list