Th: dropping athlon and maybe deprecating ppc?

Radoslaw Zielinski radek at pld-linux.org
Thu Mar 12 12:11:35 CET 2009


Pawel Golaszewski <blues at pld-linux.org> [10-03-2009 21:58]:
> On Tue, 10 Mar 2009, Elan Ruusamäe wrote:
>> /usr/lib/perl5/vendor_perl/5.8.0/athlon-pld-linux-thread-multi

> I'm wondering if we _really_ need to have that dir in this form? If I'll 

Probably not.

> put perl module to that directory from i386 it'll simply work (or I'm 
> wrong?).

I'm not sure if it'll always be correct, but likely yes.

> Why not try change it to something less problematic, for whole 
> line: x86-pld-linux-thread-multi, x8664-pld-linux-thread-multi,... or 
> maybe just "arch-pld-linux-thread-multi" (what about multilib in this 
> moment?)

-1: it's a major change and I can't see a good reason to warrant it.
The pain will be much bigger, than the gain [1].

  $ perl -le 'map print, @INC' | grep /lib/
  /usr/local/lib/perl5/5.10.0/i686-pld-linux-thread-multi
  /usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi
  /usr/lib/perl5/5.10.0/i686-pld-linux-thread-multi

If we touch the first one, we'll screw over everyone who installed
something using CPAN.pm.  People do that on production, a lot.  We
*might* consider doing a mv in a %trigger*, but that would violate
the "packages do not touch /usr/local" rule.

2nd one... custom-built packages without directory dependencies will
cause trouble, but that's probably not many people.

I'm not sure if trees built with "perl Makefile.PL LIB=~/.lib" would
be affected; if they were -- ouch, that's major.

> I don't know how difficult is it, but it seems that rpm macros change and 
> rebuild perl will be enough (...and modules rebuild, of course :) ).

Easy, no need to change the macros; just a couple of %defines in
perl.spec.  But do not do it without a *really* good reason and
thinking it over.


[1] If we were to push this pain through (forcing everyone to rebuild
    their custom-built perl stuff), it might be worth to consider
    disabling ithreads, to get two gains in one go.  That's about 10%
    performance gain, and I have yet to encounter an application which
    uses these.
    It would be useful to talk to other distributors first, though.

-- 
Radosław Zieliński <radek at pld-linux.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : /mailman/pipermail/pld-devel-en/attachments/20090312/e175c5ff/attachment.sig 


More information about the pld-devel-en mailing list