Marius Feraru <altblue@xxxxxxx> writes:
> [My apologies for my digression, feel free to ignore it.]
>
> Robin Norwood wrote:
>> /usr/lib/perl5/{5.8.6,5.8.7,5.8.8}
>> So that rpms built for older releases will still work. It's kindof
>> nasty, but as I understand it, it was to prevent having to rebuilt all
>> the perl modules when perl does a point release. I think we can deal
>> with this a lot better from an infrastructure point of view than in the
>> old days...though a big red 'rebuild all of perl magically' button would
>> be nice.
>
> Now, if you're talking about a major "all Perl related" rebuild, maybe this
> could be a good point for raising a "better" (YM*M*V) Perl infrastructure:
>
> a) let "site" be "site" (as in "local" IS "local"), e.g.:
> ./Configure [..]
> -Dsiteprefix=/usr/local \
> -Dsitelib="/usr/local/lib/perl5" \
> -Dsitearch="/usr/local/lib/perl5/%{perl_archname}" \
> -Dsiteman1dir=/usr/local/share/man/man1 \
> -Dsiteman3dir=/usr/local/share/man/man3 \
> [...]
> (if some of you think Debian like, than paranoid may be good, so you
> could decide involving a %{perl_version} there as some handy/safe
> "site" handler - not that it would matter, but I'd nay it)
This seems to me to be perfectly sane and more in keeping with the LSB
filesystem guidelines. I'm not sure all of the historical reasons for
the way our paths are set up. I don't have an objection to changing
them after some debate, though.
> b) no more creepo "compat stuff", let there be a "perl(abi..)" BS of some
> kind if you need it (IMHO, there *is* an inherent need for something like
> that for RPM's sake), e.g.:
> ./Configure [..]
> [...]
> -Dprivlib=%{_datadir}/perl/%{perl_abi}
> -Darchlib=%{_libdir}/perl/%{perl_abi}
> -Dvendorlib=%{_datadir}/perl/%{perl_abi}
> -Dvendorarch=%{_libdir}/perl/%{perl_abi}
> (yes, "vendor" should be the very same thing as "priv", and "perl_abi"
> should be anything "Fedora Perl master" decides - "5.8", "5.10", etc)
>
> As you may have noticed, there is nothing new here, they're proved paths by
> (many) other *nix distros ("Debian" will be my only example, as I already
> had to mention it).
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.
> On a different cue ("rant-wise"), looking at the "split" thingie, there is
> still a lot more to require from upstream (I mean "rpm" - you know,
> perl.prov/req & co) until we could get some "real" (as in "useful"... or
> maybe "granular"?) require/provide computing. But that (again) is handled
> with as much care as it could be imposed for a voluntary project by the many
> Fedora Perl modules packagers.
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.
-RN
--
Robin Norwood
Red Hat, Inc.
"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
