time for perl 5.10.x in devel?

Robin Norwood rnorwood at redhat.com
Mon Dec 10 16:50:26 UTC 2007


"Chris Weyl" <cweyl at alumni.drew.edu> writes:

> On Dec 6, 2007 8:35 AM, Robin Norwood <rnorwood at redhat.com> wrote:
>> "Rafael Garcia-Suarez" <rgarciasuarez at gmail.com> writes:
>> > What's the perlmodcompat stuff, if I may ask?
>>
>> This is the business that creates the directories:
>>
>> /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.
>
> I'm not opposed to dropping it in principle, but do we have a nice way
> to determine that a built rpm will work with a given perl rpm?  E.g.
> If we have perl-Foo, a noarch perl package built against 5.10.:
>
> a) will we need to rebuild it against 5.10.1?
> b) do we have meta-information embedded in the rpm that will let
> yum/apt go "this no workie"?
>
> a is just an awareness issue, and maybe the building out of a Big Red
> Button.  b is pretty clutch, or we're going to break a bunch of
> stuff...

Well, for b), we still have: Provides: perl(:MODULE_COMPAT_5.10.0) in
the perl RPM, and:

Requires:       perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))

In all of our Fedora RPMs.  The way the 5.10.0 rpm is now, that will
require that all of the perl RPMs be specifically built for 5.10.0
before they can be installed.  When 5.10.1 rolls around, we could
either:

1) Return to creating the permodcompat directories, and include Provides
for both 5.10.0 and 5.10.1.

2) Rebuild the whole darn world (and make people download all those
updates if we do it during a release).

Neither seems particularly appealing to me, to be honest.  But if we
already know we're going to do (1), we might as well leave the rest of
the perlmodcompat spec stuff in.

>> > Except perl-version, which is really tied to the core, I assume you can
>> > make them subpackages, if that would ease upgrading them separately.
>>
>> Ok.  I'll leave that in for now.
>
> I'm starting to relax on this :)  I do think any version bumps of
> dual-life'd core modules, outside of a core upgrade itself,  ought to
> be the subject of discussion here.

Yes, I agree.

-RN

-- 
Robin Norwood
Red Hat, Inc.

"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching




More information about the perl-devel mailing list