Weirdness in F-13/rawhide builds...

[Chris Weyl]

On Fri, Jan 15, 2010 at 5:33 PM, Stepan Kasal <skasal at redhat.com> wrote:
>> I noticed that %perl_vendorlib was evaluating to /usr/share/perl5.
>
> it is definitely intentional, part of the long-planned @INC cleanup.

Gotcha.

>> Checking out devel/perl.spec I see it defined this way as well;
>> unversioned, and undifferentiated from core.
>
> Yes, it is unversioned.  Modules built against perl-5.10.1 can be
> supposed to work with 5.10.2,3,4,5,... as well, and it is not nice to
> collect all these versined paths in @INC.

So...  Why not just trim it to 5.10?  By dropping the versioning
entirely, we're making it much more difficult for people who may want
to have other perls installed in parallel (e.g. 5.8.x for some custom
XS bits they can't or won't recompile against 5.10.x).  I realize this
may be a rare case, but we don't gain anything by eliminating it.

Also, I just realized that we've dropped the arch from the end (e.g.
x86_64-linux-thread-multi).  Why?

Both of these changes prevent, say, using a shared /usr directory
between machines; more precisely prevent using a shared /usr between
two machines of different architectures.  (e.g. i386/x86_64)  I don't
know if this is a big deal or not out there in the Real World, but I'm
not sure why we'd make it more difficult.  What problem are we solving
here?  Is there some significant benefit we realize from this that I'm
missing?

> And yes vendorlib = privlib.  Both the core modules and vendor
> modules are controled by rpm dependency mechanisms (mainly
> perl(:MODULE_COMPAT_5.10.x) provide), and I do not see any point in
> having these two trees separated.  And we save two elements in the
> @INC path.

Hmm.  Sooo...  It actually doesn't work out that way; we just see
privlib/arch repeated:

[cweyl at athena perl-5.10.1-109.fc13.x86_64]$
LD_LIBRARY_PATH=./usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE/
./usr/bin/perl -V
Can't locate Config.pm in @INC (@INC contains: /usr/local/lib64/perl5
/usr/local/share/perl5 /usr/local/share/perl5 /usr/lib64/perl5
/usr/share/perl5 /usr/share/perl5 /usr/lib64/perl5 /usr/share/perl5
/usr/local/lib64/perl5/site_perl/5.10.0/x86_64-linux-thread-multi
/usr/local/lib/perl5/site_perl/5.10.0
/usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl
/usr/lib/perl5/site_perl .).

Or, put another way, @INC is:

/usr/local/lib64/perl5
/usr/local/share/perl5
/usr/local/share/perl5
/usr/lib64/perl5
/usr/share/perl5
/usr/share/perl5
/usr/lib64/perl5
/usr/share/perl5
/usr/local/lib64/perl5/site_perl/5.10.0/x86_64-linux-thread-multi
/usr/local/lib/perl5/site_perl/5.10.0
/usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.10.0
/usr/lib/perl5/vendor_perl
/usr/lib/perl5/site_perl
.

We're not really gaining anything here; certain paths will just be
checked multiple times, as Perl recognizes site/vendor/core no matter
how we define them.  So, we're making another major deviation from how
upstream does it, that doesn't solve a non-existent problem, and which
appears to break other functionality.

Even if we push all of our packaged dists to privlib/arch, why not
keep vendorlib/arch around as distinct directories?  I can see cases
where it'd be useful (e.g. a university/corporation or other 3rd party
wanting to distribute custom modules/content in a way that conflicts
with neither "core" nor site).

>> Not to put too fine a point on it, is this intentional? :) It appears
>> to be playing havoc with install_share / Module::Install::Share (hence
>> the FTBFS), causing share files to be installed under /blib.
>
> Let me suppose this is fixable in Module::Install ...
> I hope I'll get to it eventually; but every bit of help is welcome,
> of course.  ;-)

I'm pretty sure that if Module::Install is broken here, we're the ones
that did it :)  It's worth noting too that even if we patch
Module::Install via our rpm/spec, any dist that uses install_share()
will contain a bundled Module::Install::Share.  There is at least one
spec out there that just nukes the /blib directory (perl-Padre); I'm
not sure if it's significant but there's no comment as to why and a
build locally shows about 2x as many files under .../dist/Padre/ than
the rawhide build.

I haven't checked yet to see if this change impacts File::ShareDir, too.

I'm more than willing to help where needed, but I'm having a hard time
seeing what we gain (and how it offsets the issues it causes) and what
problem we're solving by making these changes.

                                                       -Chris
-- 
Chris Weyl
Ex astris, scientia