"Rafael Garcia-Suarez" <rgarciasuarez@xxxxxxxxx> writes:
> On 05/12/2007, Robin Norwood <rnorwood@xxxxxxxxxx> wrote:
>> o Most of our patches to 5.8.8 are either applied in 5.10.0, or fixed
>> differently.
>> - Many due to spot submitting all of them upstream when he
>> did the package review. Spot rocks.
>
> Submitting upstream rocks. I'd like more vendors to do this.
>
>> - The others seem to be RH/Fedora specific, including the diddling we
>> do with the path for the perlmodcompat stuff.
>>
>> o Speaking of the perlmodcompat stuff - is 5.10.0 a good time to get rid
>> of it? Or we be kicking ourselves when 5.10.x is released and we need
>> to rebuild everything?
>
> 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.
>> o A bunch of formerly CPAN modules have been moved into core. Here's an
>> incomplete list:
>
> You'll get a full list from pod/perl5100delta.pod.
Oh, excellent.
> [...]
>> - 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.
>> o Some of the packages that we split into subpackages for 5.8.8 didn't
>> change version in 5.10.0:
>>
>> perl-ExtUtils-MakeMaker-6.30
>> perl-Test-Harness-2.56
>> perl-CPAN-1.76
>> perl-ExtUtils-Embed-1.26
>> perl-Test-Simple-0.62
>>
>> This means that the release field for the 5.8.8 packages will be 31 (or
>> whatever), while the release field for 5.10.0 will probably start at
>> 1...meaning the 5.8.8 versions will win vercomp.
>>
>> How to fix it?
>>
>> - Start at whatever the last perl.5.8.8 release is + 1? (Yuck!)
>
> Forget it: that could cause problems with intermediate perl upgrades
> for 5.8.8 in maintenance branches (like, security fixes).
>
>> - Epoch (double yuck!)
>
> Epoch isn't nice, but works, it wouldn't dismiss it from the start.
>
>> - Something smarter? (Smarter would be good)
>
> Smarter means tricky. My two cents: you could produce those subpackages
> with a Requires on perl-base >= 5.10.0 and a Conflicts on perl-base <
> 5.10.0. Not sure how upgraders (as yum) will cope with that though.
Eeeh. Tricky.
Yeah, epoch is probably the way to go.
-RN
--
Robin Norwood
Red Hat, Inc.
"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
