subversion-perlbindings: remove support for obsolete perl versions

[dbevans (David B. Evans)]

The following are the only remaining dependents of obsolete perl5.8 through perl5.14

subversion-perlbindings-5.8
subversion-perlbindings-5.10
subversion-perlbindings-5.12
subversion-perlbindings-5.14

Dependents p5-svn-mirror and p5-svn-simple now only support perl5.16 through perl5.20.

[danielluke (Daniel J. Luke)]

Do we have a recipe for this? are we just removing the older perls from perl5.branches, or are we trying to provide some sort of transition for people who may have an older p5 port installed?

[larryv (Lawrence Velázquez)]

We’re generally using replaced_by to “upgrade” people using older Perl ports to the 5.16 versions (see #46322).

[danielluke (Daniel J. Luke)]

Replying to larryv@…:

We’re generally using replaced_by to “upgrade” people using older Perl ports to the 5.16 versions (see #46322).

Ok, so I need to add subversion-perlbindings to the obsolete p5-graveyard port and then remove the older perls from p5.branches in the subversion-perlbindings port itself?

[danielluke (Daniel J. Luke)]

Replying to dluke@…:

Replying to larryv@…:

We’re generally using replaced_by to “upgrade” people using older Perl ports to the 5.16 versions (see #46322).

Ok, so I need to add subversion-perlbindings to the obsolete p5-graveyard port and then remove the older perls from p5.branches in the subversion-perlbindings port itself?

actually, will this just not work because p5-graveyard expects the subports to be ^{p5.X and the subversion-perlbindings port don't match that pattern?}

[larryv (Lawrence Velázquez)]

Replying to dluke@…:

actually, will this just not work because p5-graveyard expects the subports to be ^p5.X and the subversion-perlbindings port don't match that pattern?

It won’t work in the usual way, but I can shoehorn it in. You can go ahead and remove the subports from subversion-perlbindings, and I’ll add them to the graveyard afterwards.

[mojca (Mojca Miklavec)]

What about something like the following (which can probably be simplified further)?

Portfile

@@ -18 +18 @@
 
 homepage            http://subversion.apache.org/
 
-set perl5.branches {5.8 5.10 5.12 5.14 5.16 5.18 5.20}
+set perl5.branches {5.16 5.18 5.20}
 foreach branch ${perl5.branches} {
     set p_idx [lsearch ${perl5.branches} ${branch}]
     set other_perls [lreplace ${perl5.branches} $p_idx $p_idx]
@@ -30 +30 @@
         }
     }
 }
+set perl5.old_branches {5.8 5.10 5.12 5.14}
+foreach branch ${perl5.old_branches} {
+    subport ${name}-${branch} {
+        replaced_by ${name}-5.16
+        PortGroup   obsolete 1.0
+        revision    1
+    }
+}
 
 if {${subport} eq ${name}} {
 
@@ -49 +57 @@
     livecheck.url   http://svn.apache.org/repos/asf/subversion/tags/
     livecheck.regex "(\\d+\\.\\d+\\.\\d+)/"
 
+} elseif {${subport} eq "${name}-5.8" || ${subport} eq "${name}-5.10" || ${subport} eq "${name}-5.12" || ${subport} eq "${name}-5.14"} {
 } else {
 
     master_sites    apache:subversion

I don't see the need to try to hack the p5-graveyard port any further. It does its job to handle thousands of standard ports, but I don't see why this simple exception couldn't be handled inside the subversion-perlbindings port itself.

[danielluke (Daniel J. Luke)]

Replying to mojca@…:

What about something like the following (which can probably be simplified further)?

besides the ugly elsif that's there, presumably putting it in p5-graveyard makes things better when we finally make the macports default perl the current one?

I don't really care either way.

[danielluke (Daniel J. Luke)]

Removed older perls in r131061, I can add them back with replaced_by foo if we decide that that's what's best (or larryv can add them to p5-graveyard).

[mojca (Mojca Miklavec)]

Replying to dluke@…:

Replying to mojca@…:

What about something like the following (which can probably be simplified further)?

besides the ugly elsif that's there,

Yes, I agree that the "elsif" is a tiny bit ugly, but I was hoping for a hacker to come up with a nicer solution. I was merely pointing to the direction that I would pick.

presumably putting it in p5-graveyard makes things better when we finally make the macports default perl the current one?

Can you please explain what you meant with that? I don't understand how exactly subversion-perlbinding in p5-graveyard would make anything better, cleaner or easier in the future. And what did you mean with "make the macports default perl the current one"? The switch to 5.20?

[danielluke (Daniel J. Luke)]

Replying to mojca@…:

Can you please explain what you meant with that? I don't understand how exactly subversion-perlbinding in p5-graveyard would make anything better, cleaner or easier in the future.

fewer places to deprecate future perl versions

And what did you mean with "make the macports default perl the current one"? The switch to 5.20?

yes (although it might not be 5.20 by the time we get around to it). Perhaps we'll get read of the p5.xx foo at that point and just have p5- ports that work with the current perl by then, though (one can hope).

[larryv (Lawrence Velázquez)]

Replying to dluke@…:

Replying to mojca@…:

Can you please explain what you meant with that? I don't understand how exactly subversion-perlbinding in p5-graveyard would make anything better, cleaner or easier in the future.

fewer places to deprecate future perl versions

It also prevents future changes to subversion-perlbindings from causing spurious Buildbot failures. This is the actual purpose of the graveyard metaports.

Anyway, r131075.