Re: time for perl 5.10.x in devel?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

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

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

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

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

[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Legacy Announce]     [Fedora PHP Devel]     [Kernel Devel]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Big List of Linux Books]     [Gimp]     [Yosemite Information]
  Powered by Linux