time for perl 5.10.x in devel?

Marius Feraru altblue at n0i.net
Mon Dec 10 00:14:54 UTC 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[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)

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).

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.

Cheers
- --
Marius Feraru
-----BEGIN PGP SIGNATURE-----

iD8DBQFHXIT+tZHp/AYZiNkRAmSqAJ9xtOHfZn4s+qF/tAChfVKI04XMIQCfQgDy
YhdIbH8e8yK7g/GYYnX376A=
=txiY
-----END PGP SIGNATURE-----




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