[gentoo-perl] [RFC] Some thoughts on the next release of perl

[gentoo-perl] [RFC] Some thoughts on the next release of perl

[Michael Cummings]

[-- Attachment #1: Type: text/plain, Size: 3961 bytes --]

* 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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-perl] [RFC] Some thoughts on the next release of perl

[Alex Efros]

[-- Attachment #1: Type: text/plain, Size: 901 bytes --]

Hi!

On Tue, Apr 03, 2007 at 07:40:19AM -0400, Michael Cummings wrote:
> * Redoing the re-order @INC patch - I've had discussions lately with folks, both

Good idea. Right now I use workaround to use my modules in site_perl:
1) I've installed fresh modules from CPAN.
2) I've unmerged Gentoo's modules (because of @INC re-ordering issue).
3) I've fill /etc/portage/profile/package.provided to avoid installing them
   again by emerge -uDNa world. I use something like:

{ perl -le 'use DBI;        print "dev-perl/DBI-",       $DBI::VERSION';
  perl -le 'use DBD::mysql; print "dev-perl/DBD-mysql-", $DBD::mysql::VERSION';
  perl -le 'use XML::Simple;print "dev-perl/XML-Simple-",$XML::Simple::VERSION';
  perl -le 'use XML::Parser;print "dev-perl/XML-Parser-",$XML::Parser::VERSION';
} >> /etc/portage/profile/package.provided

Maybe it's good idea to automate this in some way...

-- 
			WBR, Alex.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-perl] [RFC] Some thoughts on the next release of perl

[Michael Cummings]

[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]

On Tue, Apr 03, 2007 at 06:42:17PM +0300, Alex Efros wrote:
> Hi!
> 
> On Tue, Apr 03, 2007 at 07:40:19AM -0400, Michael Cummings wrote:
> > * Redoing the re-order @INC patch - I've had discussions lately with folks, both
> 
> Good idea. Right now I use workaround to use my modules in site_perl:
> 1) I've installed fresh modules from CPAN.
> 2) I've unmerged Gentoo's modules (because of @INC re-ordering issue).
> 3) I've fill /etc/portage/profile/package.provided to avoid installing them
>    again by emerge -uDNa world. I use something like:
> 
> { perl -le 'use DBI;        print "dev-perl/DBI-",       $DBI::VERSION';
>   perl -le 'use DBD::mysql; print "dev-perl/DBD-mysql-", $DBD::mysql::VERSION';
>   perl -le 'use XML::Simple;print "dev-perl/XML-Simple-",$XML::Simple::VERSION';
>   perl -le 'use XML::Parser;print "dev-perl/XML-Parser-",$XML::Parser::VERSION';
> } >> /etc/portage/profile/package.provided
> 
> Maybe it's good idea to automate this in some way...


rather than use $MODULE::VERSION, you may want to use a hard number (like 9999)
- I only mention it because sometimes we have to alter the upstream version
numbers so that portage can understand that version 0.5 is greater than version
0.401 (which portage doesn't interpret as a decimal, but instead as a version
seperator). Just something to think about :) (though I think getting the reorder
patch updated would help you out a lot too).

~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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-perl] [RFC] Some thoughts on the next release of perl

[Christian Hartmann]

> * 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.

Why not just give the choice to the user and create a new useflag 
(e.g. 'vanilla-inc') to toggle this? 

--
Christian Hartmann
http://www.gentoo.org/~ian/

PGP Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2154E5EE692A4865
Key fingerprint = 4544 EC0C BAE4 216F 5981  7F95 2154 E5EE 692A 4865

-- 
gentoo-perl@gentoo.org mailing list

Re: [gentoo-perl] [RFC] Some thoughts on the next release of perl

[Michael Cummings]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

On Wed, Apr 04, 2007 at 10:11:25AM +0200, Christian Hartmann wrote:
> 
> Why not just give the choice to the user and create a new useflag 
> (e.g. 'vanilla-inc') to toggle this? 

I was going to point out that when we had a vanilla @INC was when we had
problems with perl-core modules (as they now are) overwriting core modules,
which really broke things when unmerged...but that was before we were forcing
everything to install into vendor as well...so yeah, that might just work :)

But then it begs the question, why not just go with vanilla at that point? (I
know there has to be an argument against this, I just can't remember what it
might be.)

-- 

-----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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-perl] [RFC] Some thoughts on the next release of perl

[Jeff Rollin]

On 04/04/07, Michael Cummings <mcummings@gentoo.org> wrote:
> On Wed, Apr 04, 2007 at 10:11:25AM +0200, Christian Hartmann wrote:
> >
> > Why not just give the choice to the user and create a new useflag
> > (e.g. 'vanilla-inc') to toggle this?
>
> I was going to point out that when we had a vanilla @INC was when we had
> problems with perl-core modules (as they now are) overwriting core modules,
> which really broke things when unmerged...but that was before we were forcing
> everything to install into vendor as well...so yeah, that might just work :)
>
> But then it begs the question, why not just go with vanilla at that point? (I
> know there has to be an argument against this, I just can't remember what it
> might be.)
>
> --
>
> -----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.
>
>


-- 
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.  - Richard Phillips Feynman

http://latedeveloper.org.uk
-- 
gentoo-perl@gentoo.org mailing list

Re: [gentoo-perl] [RFC] Some thoughts on the next release of perl

[Antoine Raillon]

Michael Cummings a écrit :
> * 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).
>   
Agree. not really my domain but I can't think of any problems if we 
reverse this one.. moreover it seems a bit more logical to me ;)
> * Redoing the re-order @INC patch
If I summarize we'll have site->vendor->core, +versionning of everything 
? Seems quite fine to me. Plus with the project i'm working on with 
Michele right now, It'll probably be quite common to need CPAN modules 
directly for the users we target (either because of the stabilization 
delay, either because something is not in the tree).
btw I see one question here, about g-cpan : I love this small tool but 
it puts modules to vendor (as they're added by portage), so de-reversing 
@INC in favor of site will probably push users to use CPAN/CPANPLUS 
directly instead of g-cpan. Is it a problem ?
> * 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.
>
>   
That would be quite nice, but won't it be a problem with modules 
requiring a specific version of libperl.so ? And if we also change 
modules directories to match perl version, some modules may disappear to 
the user's view while portage says they're here, isn't it ? I feel I'm 
missing something here ;)

second point, is there a reason/policy in favor of a perl-config tool 
more than an eselect module ?

++,
cab

-- 
gentoo-perl@gentoo.org mailing list

Re: [gentoo-perl] [RFC] Some thoughts on the next release of perl

[Michael Cummings]

[-- Attachment #1: Type: text/plain, Size: 1967 bytes --]

On Wed, Apr 04, 2007 at 04:08:44PM +0200, Antoine Raillon wrote:
> >* Redoing the re-order @INC patch
> btw I see one question here, about g-cpan : I love this small tool but 
> it puts modules to vendor (as they're added by portage), so de-reversing 
> @INC in favor of site will probably push users to use CPAN/CPANPLUS 
> directly instead of g-cpan. Is it a problem ?

easily fixed with some eclass magic (we should get after your mentor to show you
the ins and outs of the eclasses - and for those of you not sure, I'm cab's
mentor :)

> That would be quite nice, but won't it be a problem with modules 
> requiring a specific version of libperl.so ? And if we also change 
> modules directories to match perl version, some modules may disappear to 
> the user's view while portage says they're here, isn't it ? I feel I'm 
> missing something here ;)

well, what i was trying to suggest (but this goes back to fiddling with @inc
patch) is to create an agnostic vendor directory that is devoid of perl version
information so that it's always /usr/lib/perl5/vendor_perl for portage installed
modules - but this is said without actually see if it would work with a slotted
perl. Might make more headaches than it's worth (at which point, what's the
point in a slotted perl if you have to rebuild everything multiple times perl
perl).

> 
> second point, is there a reason/policy in favor of a perl-config tool 
> more than an eselect module ?

nope. me grok bash, no grokie grok eselect :)


> ++,
> cab
> 
> -- 
> gentoo-perl@gentoo.org mailing list
> 

-- 

-----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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]