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!
email@example.com mailing list