time for perl 5.10.x in devel?

Marius Feraru altblue at n0i.net
Tue Dec 11 02:26:45 UTC 2007

Hash: SHA1

Robin Norwood wrote:
> I'm probably missing the point, but I don't really see how this is
> significantly better than the way we do the perlmodcompat stuff now.

Let's detail what these changes mean:
a) using "ABI based" layout (instead "version based");
b) moving "arch independent" components in "/usr/share";
c) unifying "install" and "vendor" folders;
d) moving "site" folders to "/usr/local".

So here's what comes to mind as (maybe not so significant) advantages:
- - [a),c)] less items in @INC [1] => faster module/functions loading => light
performance gain;
- - [b),c),d)] more FHS conformity;
- - [a),c),d)] less rebuilds/updates/conflicts/metadata => vendor maintenance
cost reduction;
- - [d)] leveraging local sysop's job/ownership [2];
...(FIXME: add more pros and - more importantly - *cons*)...

[1] a "uniq" patch is needed in order to drop duplicate paths from @INC.

[2] a vendor update would not override sysop's "temporary" system
"patching", so that's why Debian (among others) prefers adding "precise"
(version based) suffixes to locally maintained folders (e.g.
"/usr/local/lib/perl/5.10.0" instead "/usr/local/lib/perl/5.10").

> Well, RH/Fedora are spending more resources on our variant of RPM these
> days, so there's a there's a better chance that specific bugs will get
> attention, or, even better, patches.
Hehe, as I mentioned, I was merely "ranting" as I'm pretty confident the
current approach used by perl.(prov|req) (or perldeps.pl) will lead us
nowhere even if we keep on monkey patching it on a daily/package basis. As
I'm sure you know, each vendor uses its "custom" way of detecting these
dependencies/provides, each with its own flaws. :)
I guess we will talk about patches in January, when we'll deal with rpm5's
perl helper ;-)

- --
Marius Feraru


More information about the Fedora-perl-devel-list mailing list