perl @INC (paths) again

[Petr Pisar]

On Wed, Feb 02, 2011 at 10:43:10AM +0000, Paul Howarth wrote:
> However, the plan envisages third-party repositories sticking with 
> vendor directories and I'm not sure that's going to happen. If I need a 
> module for my own repository and Fedora already has some version of it, 
> I just grab that version, update it as necessary and built it. So I'll 
> inherit the use of the perl/core directories unless I explicitly revert 
> back to vendor directories. Other repositories might also want to 
> maintain as close compatibility with Fedora as possible and would use 
> that as justification for using perl/core too.
> 
We should not assume anything about third-party repositories. Neither how
they write their spec files (if any), nor if they are compatible. This is the
reason why I think reserving a directory just for that purpose is good
idea. Third party (= not provided by Fedora) modules should be allowed to do
what they wish and distribution should not create obstacles. I think it's
better to make Fedora more versatile than to burden developers of unoffical
distribution extenstions.

> I thought the conventional structure of having modules bundled with perl 
> (the perl core) going to perl/core directories and everything else 
> that's packaged (including dual lived modules) going to vendor 
> directories made good, intuitive sense, and I think that's what upstream 
> intended too.

Dual-lived modules. That's another problem:

Having them in the same directory as core modules allows packager to discover
clashes sooner than at run time because RPM warns you that new package tries
to overwrite file owned by another package. Also administrator gets sure there
is no remaining code from original module. This is especially important when
fixing security bugs.

On the other hand, RPM has problem with architecture specific dual-lived
packages. The problem is debuging data for all sub-packages are distributed
in one package. Thus once you install perl-debuginfo, you cannot install
debuginfo for dual-lived package because the files are stored in the same
paths. See <https://bugzilla.redhat.com/show_bug.cgi?id=664414> for more
details. Installing dual-lived modules into separate paths works around this
problem.


So, I like the idea to clean include paths and have everything on one place.
However I'm worried Fedora packaging system is not prepared for it yet.

-- Petr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/perl-devel/attachments/20110216/63c43dd1/attachment.sig>