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