Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-perl
Navigation:
Lists: gentoo-perl: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-perl@g.o
From: Michael Cummings <mcummings@g.o>
Subject: Re: Introduction and Possible New Objectives
Date: Fri, 11 Nov 2005 19:34:06 -0500
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) g-cpan.pl needs help
> 
> I've noticed that quite a few bugs in bugzilla stem from g-cpan.pl 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:  
> http://dev.gentoo.org/~mcummings/perl_updates.html.  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


References:
Introduction and Possible New Objectives
-- Chris White
Navigation:
Lists: gentoo-perl: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Introduction and Possible New Objectives
Next by thread:
g-cpan -u
Previous by date:
Introduction and Possible New Objectives
Next by date:
g-cpan -u


Updated Jun 17, 2009

Summary: Archive of the gentoo-perl mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.