On Thu, Oct 07, 2021 at 03:44:48PM -0400, Tom Lane wrote: > [ cc'ing Craig and Noah, as author/committer of the existing text ] > > Daniel Gustafsson <dan...@yesql.se> writes: > > On 7 Oct 2021, at 21:02, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> BTW, looking at that a second time, I wonder if that advice is > >> really of any use. > >> > >> (1) I'm distrustful of the idea that perl 5.8.x will compile > >> cleanly, or at all, on modern platforms. Certainly Postgres > >> releases of similar vintage won't.
perlbrew uses the patchperl system to build old Perl in modern environments. This year, I used it to get 5.8.0. Building unpatched 5.8.0 does fail. > >> (2) Unless perlbrew.pl is doing something a lot more magic than > >> I think, you're going to end up with current-not-historical > >> versions of whatever it has to pull from CPAN. That's going > >> to include at least IPC::Run and Test::More if you want to run > >> our TAP tests. Yes. If someone changed the recipe to install Test::More 0.87 and the oldest-acceptable IPC::Run, we'd detect more portability problems. I'd regard such a change as an improvement. > >> So maybe this advice is helpful, but I'm not very convinced. The rest of this thread is leaning on the above misconceptions: > I propose that what might be more useful than the existing last > section of src/test/perl/README is something along the lines of: > > Avoid using any bleeding-edge Perl features. We have buildfarm > animals running Perl versions as old as 5.8.3, so your tests will > be expected to pass on that. > > Also, do not use any non-core Perl modules except IPC::Run. > Or, if you must do so for a particular test, arrange to skip > the test when the needed module isn't present. -1. This would replace a useful recipe with, essentially, a restatement of that recipe in English words. That just leaves the user to rediscover the actual recipe.
