time for perl 5.10.x in devel?

Chris Weyl cweyl at alumni.drew.edu
Sun Dec 9 18:00:06 UTC 2007


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

[...]
> >>   - shall we just do these as subpackages?  Are there any that would be
> >>     more appropriate leaving in the main perl package?  I assume we'll
> >>     want to keep the perl-core convention Requiring the new subpackages.
> >
> > 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.

                                   -Chris

-- 
Chris Weyl
Ex astris, scientia




More information about the perl-devel mailing list