On 8/12/14 9:30 AM, Frank Schima wrote: > On Aug 12, 2014, at 10:03 AM, Mojca Miklavec <mo...@macports.org> wrote: > >> On Tue, Aug 12, 2014 at 5:23 PM, Ryan Schmidt wrote: >>>> On Aug 12, 2014, at 10:20 AM, David Evans wrote: >>>> On 8/12/14 8:06 AM, Ryan Schmidt wrote: >>>>> On Aug 12, 2014, at 9:56 AM, Mojca Miklavec wrote: >>>>>> Now about 5.8-5.16: my idea was to initially set the INC path for >>>>>> those versions in such a way that it would include >>>>>> "5.16.3/darwin-thread-multi-2level 5.16.3 >>>>>> 5.16.1/darwin-thread-multi-2level 5.16.1 >>>>>> 5.16.0/darwin-thread-multi-2level 5.16.0" as well as the "plain" >>>>>> <something>/5.16/<something> without the subrelease. That means that >>>>>> there would initially be no urgent need to revbump all the > 1000 >>>>>> ports. (On the contrary 5.20 doesn't need any change and for 5.18 I >>>>>> would make sure to revbump all p5.18-foo ports.) >>>>>> >>>>>> But I'm unable to figure out how to patch Perl to do that. The INC >>>>>> path additions seem to be ignored. >>>>> Why handle <= 5.16 differently than >= 5.18? >> Because for >= 5.18 everything will work out-of-the-box once I apply a >> huge patch (cca 300 revbumps or updates). It will work automatically >> on ports where we add 5.18/5.20 later. >> >> For <= 5.16 see below. >> >>>> Because we want them to go away? Or is the effort to do them all >>>> relatively trivial? >>> My assumption was that since a patch is already in place for perl5.20 and >>> perl5.18 it could be backported to earlier versions with minimal effort, >> We can either clean up the INC path entirely (the same way as it's >> done in 5.18 and 5.20), but then need to also revbump the remaining > >> 700 modules (which needs to be done at some point anyway, if nothing >> else because we'll have to add 5.18 and 5.20 and also because half of >> those modules needs an update). But then this would have to be done >> "at once". >> >> My idea of a relatively trivial fix was to change the path where >> perl5.16 installs files, so that perl would keep looking at the old >> locations. It turned out that the patch wasn't exactly as trivial as I >> thought it would be. And I'm not yet sure why. But I bet that the >> patch isn't that complicated either. It might be one-liner once we >> figure out what and where to fix. See >> https://trac.macports.org/ticket/43480#comment:10 >> >> Anyone willing to help me out is invited to check what exactly is >> wrong with the patch I proposed. >> >> >> So it's probably still easy to do, but not as trivial as I hoped it to be. >> >> Other reasons for handling perl5.16 differently include: >> >> - most likely there will be no perl 5.16.4 (and most certainly no perl >> 5.14.5, 5.12.6, ...), so we probably don't need to care about >> locations of modules and libraries changing in the future >> >> - once we complete support for 5.18 and 5.20, implement something like >> "5.10-foo replaced_by 5.20-foo" and switch dependencies from p5.12-foo >> to p5.20-foo, we could theoretically drop support for older perls; we >> keep 5.12 around just because lots of ports depend on it (but don't >> really need to depend on it) >> >> - versions <= 5.16 are no longer supported upstream >> >> - my patch to drop the subrelease number is not really supported >> upstream and has not been tested too extensively; it might be that >> some obscure module actually depends on the fact that the module path >> should contain three numbers; so if p5.16-foo would keep working and >> p5.18-foo not, you could point your fingers at that patch ;) >> >>> and that since Mojca plans a revbump of all perl modules anyway, before >>> that mass revbumping would be the ideal time to do that. >> Yes. The ideal time would be now. That is: if we want to do it at all. >> But patching <= 5.16 apparently means either adjusting the patch a bit >> or revbumping also the other > 700 ports at the same time (which could >> be automated). > I see no reason to change perl 5.16 or lower because they are already > working. Let’s just look forward to 5.18 and 5.20. Even if 5.18 is a lame > duck already. > > For me, the only thing holding up moving to perl 5.20 is p5.20-pdo, 5.20-wx > and possibly a few others that work fine with p5.16. > > > Cheers! > Frank >
Sounds good to me. If we can agree on this, then maybe we can move on and make some progress. Otherwise, 5.22 may be out before we make a decision Dave _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
