On Dec 6, 2007 8:35 AM, Robin Norwood <rnorwood(a)redhat.com> wrote:
"Rafael Garcia-Suarez" <rgarciasuarez(a)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