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 Fedora-perl-devel-list
mailing list