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 _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev