* libperl.a vs libperl.so - Policy dictates that whenever possible, if a library
  can be made either way, that both should be generated and provided for those
  apps that need the static library to build against. Up till now,
  sys-devel/libperl has built the dynamic library, and dev-lang/perl has built
  the static library as it built perl (and thereby linked perl against the
  static). I'd like to suggest we reverse this process - let sys-devel/libperl
  build the static library for those that need it, but build the dynamic library
  alongside perl. The benefits here would be a smaller footprint for perl, and
  less hassle if someone rebuilds perl with new use flags (such as ithreads).

* Redoing the re-order @INC patch - I've had discussions lately with folks, both
  on this list and in bugs, about the order we alter the @INC in. Our reverse
  @INC patch sets the order to vendor->site->core. For Gentoo provided modules,
  this means that any modules we provide override anything else. However, there
  are a growing number of users that prefer/need to use CPAN directly, which
  installs modules to site, meaning our ebuilds override those modules. In a
  perfect world this would be acceptable, except that if you're using CPAN
  directly, that means you have need of the module *now* - but the required qa
  periods for ebuilds (which I'm not arguing against) mean that it will be at
  least 30 days until we have a new module marked stable, assuming your arch is
  even in the list and we're on the ball (which I know I haven't always been to
  say the least). Part of this reordering would be to also reverse the order of
  how vendor/site, so that we @INC would go (for example):

  /usr/lib/perl5/vendor_perl
  /usr/lib/perl5/vendor_perl/5.8.8
  /usr/lib/perl5/vendor_perl/5.8.8/i686-linux

  for vendor (same for site_perl). The rationale being to try and keep things
  as version agnostic as possible. This coupled with my previous bullet
  (libperl.so) and my next thought (slotting perl) would, at least in theoryand
  completely untested and unconfirmed, mean that so long as the
  libperl.so.<version> that the module was built against still exists, then perl
  should be able to continue to load most of the modules. We might still need to
  do a little perl-cleaner action, but it wouldn't be nearly as painful as it
  has been in the past.

* Slotted perl - I know this was a quest of yuval's for some time, not sure what
  if any progress has been made (yuval?). My train of random thought on this is
  that perl binaries/scripts would install to
  /usr/$(get_libdir)/perl5/$(perl_version)/bin, and we would generate a
  perl-config tool, akin to (and possibly ripped from) the java-config tool
  where you could select which perl was your active perl. This would mean
  installing libperl.so to its normal location, which is actually under
  /usr/$(get_libdir)/perl5/($perl_version)/$(arch)-linux/CORE and using the
  perl-config tool to link it.


I know that I've brought these thoughts up before, and even played with them a
bit, and never made any real progress. But with the next release of perl looming
ever closer on the horizon, I'd like to see the upgrade process go much more
smoothly for our users (this last bit directed at the devs on the list, but
hopefully the rest of you won't be offended by the sentiment). perl-cleaner
works (mostly)(sometimes)(as well as can be expected), but it would be ideal to
only need such a tool in dire circumstances. Comments welcome :) 

~mcummings

-- 

-----o()o----------------------------------------------
Michael Cummings   |    #gentoo-dev, #gentoo-perl
Gentoo Perl Dev    |    on irc.freenode.net 
Gentoo/SPARC
Gentoo/AMD64
GPG: 0543 6FA3 5F82 3A76 3BF7  8323 AB5C ED4E 9E7F 4E2E
-----o()o----------------------------------------------

Hi, I'm a .signature virus! Please copy me in your ~/.signature.