p5-*: consistently remove Perl versions 5.8-5.14

[mojca (Mojca Miklavec)]

Now that the default version of Perl has been switched to 5.16 everywhere, we are currently "randomly" and inconsistently removing Perl versions 5.8-5.14 from ports. As a consequence many subports p5.12-foo probably don't build and users with older subports installed won't get the ports auto-removed.

I'm attaching a very simple script that removes old perl versions (sorry, it's written in Python, not Perl, but I don't think it matters) together with its output diff. The diff is "problematic" in the way that Portfiles will probably keep changing until (if) we decide to apply the patch, but the script should remain functional.

I'm also attaching a proposal for handling auto-upgrades. I would like to ask for feedback and opinions for that part:

PortSystem          1.0

name                p5-obsolete
version             1

set perl_versions {
    5.8 5.10 5.12 5.14
}
set perl_ports {
    io-tty 1.120.0   1
    wx     0.992.300 3
}

foreach {perl_port port_version port_revision} ${perl_ports} {
    foreach {perl_version} ${perl_versions} {
        subport p${perl_version}-${perl_port} {
            replaced_by p5.16-${perl_port}
            PortGroup   obsolete 1.0
            version     $port_version
            revision    $port_revision
        }
    }
}

# TODO: disable configure, build, ...

[mojca (Mojca Miklavec)]

A script to remove perl branches p5.8-5.14

[mojca (Mojca Miklavec)]

A diff with Perl branches 5.8-5.14 removed

[mojca (Mojca Miklavec)]

Initial attempt to create a Portfile collecting all obsolete ports

[larryv (Lawrence Velázquez)]

I’ve already created a portfile for this​, and by now it’s rather well-tested. We should adapt it for Perl instead of rolling a new one.

[larryv (Lawrence Velázquez)]

suggested Perl graveyard

[larryv (Lawrence Velázquez)]

Something like this​.

[mojca (Mojca Miklavec)]

Perfect. I wasn't aware of existence of py-graveyard. Yes, I totally agree to keep the code of p5-graveyard and py-graveyard as close to each other as possible. The code I attached was basically the same idea, only a different implementation.

The only change I would suggest to make is to leave out the individual numbers of perl versions that need a replacement. First of all it will be very difficult to figure out which versions need a replacement (we would need to go through history of every Portfile and figure out which subports have been replaced). And also: almost every port included support for all perl versions, so we don't gain almost anything by trying not to include some previously non-existing ports.

So my suggestion would be to iterate through 5.8-5.14 for every single subport. There's no need to make any extra effort to try to exclude some versions. After a year we can remove 5.8-5.14 and maybe introduce the replacement 5.16, 5.18 ->5.22 by then.

What's the best way to list all Perl (sub)ports together with their current version?

[larryv (Lawrence Velázquez)]

Replying to mojca@…:

The only change I would suggest to make is to leave out the individual numbers of perl versions that need a replacement. First of all it will be very difficult to figure out which versions need a replacement (we would need to go through history of every Portfile and figure out which subports have been replaced). And also: almost every port included support for all perl versions, so we don't gain almost anything by trying not to include some previously non-existing ports.

Sure, if you think that’s best.

So my suggestion would be to iterate through 5.8-5.14 for every single subport. There's no need to make any extra effort to try to exclude some versions. After a year we can remove 5.8-5.14 and maybe introduce the replacement 5.16, 5.18 ->5.22 by then.

We can have our cake and eat it too, allowing specific versions if desired but defaulting to 5.8–5.14.

p5-graveyard.Portfile

@@ -16 +16 @@
 
 proc unknown args {
     upvar 1 replacements replacements
+    if {[llength $args] < 3} {
+        lappend args 5.8 5.10 5.12 5.14
+    }
     foreach series [lassign $args port vers] {
         lassign [split $vers _] ver rev
         if {$rev eq ""} {
@@ -30 +33 @@
     }
 }
 
-io-tty                              1.120.0_1       5.8  5.10 5.12 5.14
-wx                                  0.992.300_3     5.8  5.10 5.12 5.14
+# SUBPORT (without "p5*-" prefix)   VERSION+REV     REPLACED SERIES (optional)
+io-tty                              1.120.0_1
+wx                                  0.992.300_3
 
 if {${subport} ne ${name}} {
     PortGroup obsolete 1.0

[larryv (Lawrence Velázquez)]

Replying to mojca@…:

What's the best way to list all Perl (sub)ports together with their current version?

Depends on how fancy you want to get. What kind of output are you looking for?

[mojca (Mojca Miklavec)]

I just need a list of ports to fill your p5-graveyard Portfile, that is:

acme-lolcat 0.0.5_3
algorithm-annotate 0.100.0_3
...
io-tty 1.120.0
...
wx 0.992.300_2
...
zeromq 0.230.0_1

I don't care if the list is prefixed by p5- since I can easily remove that part.

But now that you asked I have another suggestion. The revision of the port needs to be increased by one for every port for the obsolete PortGroup to do its job. Wouldn't it be easier/better if that increase was done automatically (somewhere after the line "lassign [split $vers _] ver rev"), so that we could simply list all the current versions of the ports, rather than having to list all ports with their revisions increased by one?

[larryv (Lawrence Velázquez)]

Replying to mojca@…:

I just need a list of ports to fill your p5-graveyard Portfile, that is:

acme-lolcat 0.0.5_3
algorithm-annotate 0.100.0_3
...
io-tty 1.120.0
...
wx 0.992.300_2
...
zeromq 0.230.0_1

This will do it, then, with all revisions bumped (assuming your port index is correct):

port -q info --index --line --name --version --revision 'p5-*' \
    | awk '{ sub(/^p5-/, "", $3); printf "%-35s %s_%s\n", $3, $1, ($2 + 1); }'

I created the graveyard in r130078; you can fill it in at your leisure. I also kept myself as maintainer, but you can add yourself if you’d like. (You might want to think twice about that because you’ll get Buildbot failure emails for every single change.)

But now that you asked I have another suggestion. The revision of the port needs to be increased by one for every port for the obsolete PortGroup to do its job. Wouldn't it be easier/better if that increase was done automatically (somewhere after the line "`lassign [split $vers _] ver rev`"), so that we could simply list all the current versions of the ports, rather than having to list all ports with their revisions increased by one?

I thought about it but decided that I didn't want the portfile to list one revision but generate a subport with a different revision. I don’t like that particular kind of action-at-a-distance.

[dbevans (David B. Evans)]

This will do it, then, with all revisions bumped (assuming your port index is correct):

port -q info --index --line --name --version --revision 'p5-*' \
    | awk '{ sub(/^p5-/, "", $3); printf "%-35s %s_%s\n", $3, $1, ($2 + 1); }'

I created the graveyard in r130078; you can fill it in at your leisure. I also kept myself as maintainer, but you can add yourself if you’d like. (You might want to think twice about that because you’ll get Buildbot failure emails for every single change.)

I agree. We should first remove all remaining p5.8-p5.14 subports from perl ports. I see no impediment to doing that now. Then p5-graveyard can be filled in once and for all.

[mojca (Mojca Miklavec)]

One more question: what's the proper way to handle ports like p5-email-mime-modifier which were replaced_by another port already? (There is a similar situation with ports like p5-foo that have been replaced_by p5-bar, while p5-bar has been replaced_by p5.16-bar.)

[mojca (Mojca Miklavec)]

Your solution hack with p5-graveyard doesn't work properly in all cases. It fails at

error 0.170.220_2
eval 2.2.8_4
lchown 1.10.0_2
switch 2.170.0_1

for example.

[mojca (Mojca Miklavec)]

Also, I wouldn't try to put extra spaces into the file just in order to make it look nice. We would need 41 columns (not just 35) and that makes the file size twice the original. It might be ok for Python, but for Perl every byte that's saved counts.

[larryv (Lawrence Velázquez)]

Replying to mojca@…:

One more question: what's the proper way to handle ports like p5-email-mime-modifier which were replaced_by another port already? (There is a similar situation with ports like p5-foo that have been replaced_by p5-bar, while p5-bar has been `replaced_by p5.16-bar`.)

Leave them out? If a port has been replaced already, then there’s no need to do anything else with it.

[mojca (Mojca Miklavec)]

Replying to larryv@…:

Replying to mojca@…:

One more question: what's the proper way to handle ports like p5-email-mime-modifier which were replaced_by another port already? (There is a similar situation with ports like p5-foo that have been replaced_by p5-bar, while p5-bar has been `replaced_by p5.16-bar`.)

Leave them out? If a port has been replaced already, then there’s no need to do anything else with it.

Take the following example:

PortSystem          1.0
PortGroup           perl5 1.0

perl5.branches      5.10 5.12 5.14 5.16 5.18 5.20
perl5.setup         Test-Tester 0.109
revision            1
license             {Artistic-1 GPL}

if {${perl5.major} != ""} {
    replaced_by     p${perl5.major}-test-simple
} else {
    replaced_by     p5-test-simple
}

PortGroup           obsolete 1.0

Should I keep the branches 5.10-5.14 in the "obsolete" Portfile?

[larryv (Lawrence Velázquez)]

Replying to mojca@…:

Your solution hack

That was uncalled for. This whole concept is a hack.

with p5-graveyard doesn't work properly in all cases. It fails at

error 0.170.220_2
eval 2.2.8_4
lchown 1.10.0_2
switch 2.170.0_1

for example.

Ugh, anything that’s already a Tcl command. That’s unfortunate.

[larryv (Lawrence Velázquez)]

Replying to mojca@…:

Also, I wouldn't try to put extra spaces into the file just in order to make it look nice. We would need 41 columns (not just 35) and that makes the file size twice the original. It might be ok for Python, but for Perl every byte that's saved counts.

I think readability is much more valuable than saving a few kilobytes in this one file. Plus, there aren’t that many names that would overflow, and it isn’t a big deal when they do.

[mojca (Mojca Miklavec)]

My plan would be to wait for the buildbots to finish compiling py-graveyard (the buildbot processes just 10 ports per minute), then make a commit with 5.8-5.14 removed from all Perl ports (except for maybe the obsolete ones), then wait for someone to come up with a solution for those four ports (p5-error, ...) and finally submit p5-graveyard.

I expect p5-graveyard to take 7-8 hours to process, so I would suggest to manually stop the compilation of that file (and possibly try not to touch it for another year when all the replacements might be removed ;)

[larryv (Lawrence Velázquez)]

Replying to mojca@…:

Take the following example:

PortSystem          1.0
PortGroup           perl5 1.0

perl5.branches      5.10 5.12 5.14 5.16 5.18 5.20
perl5.setup         Test-Tester 0.109
revision            1
license             {Artistic-1 GPL}

if {${perl5.major} != ""} {
    replaced_by     p${perl5.major}-test-simple
} else {
    replaced_by     p5-test-simple
}

PortGroup           obsolete 1.0

Should I keep the branches 5.10-5.14 in the "obsolete" Portfile?

I’ve just been leaving portfiles like this out of the graveyard. There don’t seem to be that many, judging from a rough search:

% port file 'p5-*' | xargs grep -l replaced_by | wc -l
       8
%

[mojca (Mojca Miklavec)]

Replying to larryv@…:

Replying to mojca@…:

Also, I wouldn't try to put extra spaces into the file just in order to make it look nice. We would need 41 columns (not just 35) and that makes the file size twice the original. It might be ok for Python, but for Perl every byte that's saved counts.

I think readability is much more valuable than saving a few kilobytes in this one file. Plus, there aren’t that many names that would overflow, and it isn’t a big deal when they do.

Why do you need or want readability in that file? In contrast to python modules my idea was to write the list of modules once and then forget about it for one year until we'll be able to remove the replacements (or add new ones to remove 5.16, 5.18, ...).

The size penalty for adding the spaces is cca. 30 kB.

[mojca (Mojca Miklavec)]

Replying to larryv@…:

Replying to mojca@…:

Should I keep the branches 5.10-5.14 in the "obsolete" Portfile?

I’ve just been leaving portfiles like this out of the graveyard. There don’t seem to be that many, judging from a rough search:

% port file 'p5-*' | xargs grep -l replaced_by | wc -l
       8
%

I have some problems understanding what exactly replaced_by does in p5-eperl: does it only replace p5-eperl with p5.16-eperl? Why does that port reimplement half of the perl PortGroup's functionality?

My question still stands. OK, I'll leave those few ports out (it's easy to do), but should I keep 5.10 5.12 5.14 in the file? Is it OK to have the following replacement chain?

p5.10-test-tester -> [replaced_by] -> p5.10-test-simple -> [replaced_by] -> p5.16-test-simple

[larryv (Lawrence Velázquez)]

Replying to mojca@…:

Why do you need or want readability in that file? In contrast to python modules my idea was to write the list of modules once and then forget about it for one year until we'll be able to remove the replacements (or add new ones to remove 5.16, 5.18, ...).

The size penalty for adding the spaces is cca. 30 kB.

I don’t know why someone might want to read it, but they might.

And 30 KB is negligible. Other than for multi-megabyte patches and the like, we’ve never cared about the sizes of files in the repository, and I don’t see why we should start doing so. It’s 2014, and we’re not paying for MacPorts’ bandwidth.

[larryv (Lawrence Velázquez)]

Replying to mojca@…:

I have some problems understanding what exactly replaced_by does in p5-eperl: does it only replace p5-eperl with p5.16-eperl?

That appears to be the case. It’s treating p5-eperl as a stub port that just installs the default subport.

Why does that port reimplement half of the perl PortGroup's functionality?

No idea. Maybe it predates the port group?

My question still stands. OK, I'll leave those few ports out (it's easy to do), but should I keep 5.10 5.12 5.14 in the file? Is it OK to have the following replacement chain?

p5.10-test-tester -> [replaced_by] -> p5.10-test-simple -> [replaced_by] -> p5.16-test-simple

I’ve always assumed that transitive replacement worked properly, so I’ve been leaving the subports in the original portfile.

[larryv (Lawrence Velázquez)]

Replying to mojca@…:

then wait for someone to come up with a solution for those four ports (p5-error, ...)

Try r130128. Are those four the only ones?

[mojca (Mojca Miklavec)]

[I'm not claiming that those 30 kB are really problematic and I'm ok with either solution.]

Replying to larryv@…:

It’s 2014, and we’re not paying for MacPorts’ bandwidth.

Still, that's not an excuse for making inefficient programs. Yes, it's 2014, but I still wonder why it takes so much time to run "sudo port selfupdate", even though way more annoying part is that "sudo port uninstall foo" takes "forever" without any good reason (sudo port install foo is a lot faster). Sometimes I then try to keep uninstalling ports and it's soooooo annoying that I need to wait a couple of minutes between running two commands, so that I forget in the meantime what it was that I wanted to do in the first place.

There are a lot of other commands in MacPorts that take way too much time for my taste (port list ... being one of them). Being in 2014 should be merely an excuse for having a lot of tool available to speed things up.

(The fact that my browser happily consumes 6 GB of ram even when I close the majority of the windows is also not excusable by the fact that we'll be soon in 2015 ...)

[mojca (Mojca Miklavec)]

Replying to larryv@…:

Replying to mojca@…:

then wait for someone to come up with a solution for those four ports (p5-error, ...)

Try r130128. Are those four the only ones?

Thanks, I'll try.

I only had to remove those four to make "portindex" succeed. There might be others which I didn't notice (if the command didn't generate an error, I didn't notice it).

[mojca (Mojca Miklavec)]

No, it still doesn't work:

Adding subport p5.16-email-mime-modifier
Failed to parse file perl/p5-graveyard/Portfile: can't set "version": can't read "replacements(
        write {
            foreach p $option_procs($optionName) {
                $p $optionName set [set $optionName]
            }
        }
        read {
            foreach p $option_procs($optionName) {
                $p $optionName read
            }
        }
        unset {
            foreach p $option_procs($optionName) {
                if {[catch {$p $optionName delete} result]} {
                    ui_debug "error during unset trace ($p): $result\n$::errorInfo"
                }
            }
            trace add variable $optionName {read write unset} option_proc_trace
        }
    )": no such variable
Adding port perl/p5-test-tester
Adding subport p5.10-test-tester

[mojca (Mojca Miklavec)]

I attached the list of ports as generated with your one-liner (I didn't remove the obsolete ones yet). Feel free to test when and why it fails, my Tcl knowledge is far too weak.

[mojca (Mojca Miklavec)]

I removed the suports in r130129. The next step is to fix the graveyard port.

[mojca (Mojca Miklavec)]

Buildbot logs:

• 10.6: ​https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/32486
• 10.7: ​https://build.macports.org/builders/buildports-lion-x86_64/builds/25828
• 10.8: ​https://build.macports.org/builders/buildports-mtln-x86_64/builds/20177
• 10.9: ​https://build.macports.org/builders/buildports-mavericks-x86_64/builds/9645
• 10.10: ​https://build.macports.org/builders/buildports-yosemite-x86_64/builds/432

Something went wrong with the Mavericks build. It tries to build all the 5.8-5.14 ports as well.

[mojca (Mojca Miklavec)]

List of failed ports:

• Building p5-text-kakasi (407 of 3916)...failure (#46412)
  Building p5.16-text-kakasi (408 of 3916)...failure
• Building p5-text-chasen (737 of 3916)...failure (#46412, 10.10 only)
  Building p5.16-text-chasen (738 of 3916)...failure
• Building p5-macosx-file (1283 of 3916)...failure (i386-only, see also #46411, fixed by r130542)
  Building p5.16-macosx-file (1284 of 3916)...failure
• Building p5-sgmlspm (1477 of 3916)...failure (#44418, #46054, #46057)
  Building p5.16-sgmlspm (1478 of 3916)...failure
  Building p5.18-sgmlspm (1479 of 3916)...failure
  Building p5.20-sgmlspm (1480 of 3916)...failure
• Building p5-pdl (1663 of 3916)...failure (#46306)
  Building p5.16-pdl (1664 of 3916)...failure
  Building p5.18-pdl (1665 of 3916)...failure
  Building p5.20-pdl (1666 of 3916)...failure
  • Building p5-pdl-graphics-gnuplot (2093 of 3916)...failure
    Building p5.16-pdl-graphics-gnuplot (2094 of 3916)...skipping, p5.16-pdl previously failed and is needed
• Building p5-mac-carbon (1745 of 3916)...failure (#46411)
  Building p5.16-mac-carbon (1746 of 3916)...failure
  • Building p5-mac-appleevents-simple (1849 of 3916)...failure
    Building p5.16-mac-appleevents-simple (1850 of 3916)...skipping, p5.16-mac-carbon previously failed and is needed
    • Building p5-mac-apps-launch (1893 of 3916)...failure
      Building p5.16-mac-apps-launch (1894 of 3916)...skipping, p5.16-mac-appleevents-simple previously failed and is needed
    • Building p5-mac-glue (45 of 3916)...failure
      Building p5.16-mac-glue (46 of 3916)...failure
      • Building p5-mac-growl (3481 of 3916)...failure
        Building p5.16-mac-growl (3482 of 3916)...skipping, p5.16-mac-glue previously failed and is needed
  • Building p5-mac-osa-simple (3411 of 3916)...failure
    Building p5.16-mac-osa-simple (3412 of 3916)...skipping, p5.16-mac-carbon previously failed and is needed
• Building p5-opengl (2015 of 3916)...failure (#44417)
  Building p5.16-opengl (2016 of 3916)...failure
  Building p5.18-opengl (2017 of 3916)...failure
  Building p5.20-opengl (2018 of 3916)...failure
• Building p5-libapreq (2099 of 3916)...failure (depends on broken mod_perl -> Apache 1)
  Building p5.16-libapreq (2100 of 3916)...failure
• Building p5-devel-size (2251 of 3916)...failure (#46414, updated in r131066)
  Building p5.16-devel-size (2252 of 3916)...failure
• Building p5-net-cups (2679 of 3916)...failure (#35899)
  Building p5.16-net-cups (2680 of 3916)...failure
• Building p5-libapreq2 (2957 of 3916)...package found, not building again (#42582)
  Building p5.16-libapreq2 (2958 of 3916)...package found, not building again
  Building p5.18-libapreq2 (2959 of 3916)...failure
  Building p5.20-libapreq2 (2960 of 3916)...failure
• Building p5-data-alias (3867 of 3916)...failure (#46413, updated in r131057)
  Building p5.16-data-alias (3868 of 3916)...failure

[mojca (Mojca Miklavec)]

Lawrence, what about entering the ports as p5-foo (then p5-switch won't be a reserved keyword) and removing the "p5-" part inside the function?

[mojca (Mojca Miklavec)]

I would like to know/understand why ​https://build.macports.org/builders/buildports-yosemite-x86_64/builds/432/steps/cleanup/logs/stdio is trying to uninstall p5.8-foo, p5.10-foo, p5.12-foo, p5.14-foo.

[mojca (Mojca Miklavec)]

The port p5-io-compress needs some modifications/simplifications, but I need some help. The port p5-test-differences might be simplified as well.

[larryv (Lawrence Velázquez)]

Replying to mojca@…:

The next step is to fix the graveyard port.

Okay, I will look at this in a couple of hours, as soon as I get back to my computer.

[larryv (Lawrence Velázquez)]

Replying to mojca@…:

Still, that's not an excuse for making inefficient programs. Yes, it's 2014, but I still wonder why it takes so much time to run "`sudo port selfupdate", even though way more annoying part is that "sudo port uninstall foo" takes "forever" without any good reason (sudo port install foo` is a lot faster). Sometimes I then try to keep uninstalling ports and it's soooooo annoying that I need to wait a couple of minutes between running two commands, so that I forget in the meantime what it was that I wanted to do in the first place.

There are a lot of other commands in MacPorts that take way too much time for my taste (port list ... being one of them). Being in 2014 should be merely an excuse for having a lot of tool available to speed things up.

Agreed all around, although those examples are all about running-time performance and not storage, which I still maintain is cheap these days.

But here’s a compromise: Breaking our rules and using tabs saves about 30 KB, and forcing a tab width of 8 maintains my precious columns.

[larryv (Lawrence Velázquez)]

Replying to mojca@…:

I removed the suports in r130129. The next step is to fix the graveyard port.

Try r130161:130164, generating the list with this:

port -q info --index --line --name --version --revision 'p5-*' \
    | awk '
        {
            padding = (48 - length($3)) / 8
            if (padding != int(padding)) padding = int(padding) + 1
            printf "%s", $3
            for (i = 0; i < padding; ++i) printf "\t"
            printf "%s_%d%s", $1, ($2 + 1), ORS
        }'

This seemed to work for me, but I didn’t kick the tires very much.

[larryv (Lawrence Velázquez)]

Cc Me!

[mojca (Mojca Miklavec)]

I didn't spot any problem so far, so I think that the current solution could easily be used.

Just curious: would the solution be any less "hacky" if

p5-acme-lolcat 0.0.5_4

was replaced by

p5 acme-lolcat 0.0.5_4

where p5 would be a function accepting two or more arguments as opposed to having every unknown command to behave as a command? Or maybe

p p5-acme-lolcat 0.0.5_4

if switch and alike cause problems in such constructs.

I don't care that much how the aligning is done. Once again: my idea was to fill this once and then keep it that way for a year until the contents might be removed. So I wouldn't care if the file wasn't "super-readable".

Personally I don't particularly like the tabs, in particular because the rest of the file uses spaces aligned to 4. (I also didn't yet figure out how to train my editor to obey the modeline. If I set the tabs to 8, the same setting will be used on every Portfile until changed and vice versa.)

[larryv (Lawrence Velázquez)]

Replying to mojca@…:

Just curious: would the solution be any less "hacky"

There’s nothing inherently wrong with using the unknown proc in this manner. If I may say so, it’s a nice demonstration of Tcl metaprogramming and code/data duality.

if

p5-acme-lolcat 0.0.5_4

was replaced by

p5 acme-lolcat 0.0.5_4

where p5 would be a function accepting two or more arguments as opposed to having every unknown command to behave as a command?

This seems like it would invite confusion, with a space appearing where a hyphen would ordinarily go.

Or maybe

p p5-acme-lolcat 0.0.5_4

if switch and alike cause problems in such constructs.

I don’t see the advantage of this over what I have now.

I don't care that much how the aligning is done. Once again: my idea was to fill this once and then keep it that way for a year until the contents might be removed. So I wouldn't care if the file wasn't "super-readable".

Well I care, so humor me.

Personally I don't particularly like the tabs, in particular because the rest of the file uses spaces aligned to 4.

So? The rest of the file is clearly a different beast.

(I also didn't yet figure out how to train my editor to obey the modeline. If I set the tabs to 8, the same setting will be used on every Portfile until changed and vice versa.)

Are you using Vim with our mpvim “plugin”?

[larryv (Lawrence Velázquez)]

After chewing on this, it’s clear to me that this is textbook bikeshedding that should cease immediately. Let’s just worry about the replacement process; I’ll take responsibility for any graveyard weirdness.

[dbevans (David B. Evans)]

Having said this, I'd point out that the proposed attachment, ​p5-graveyard-withports.Portfile, fails parsing by portindex or port lint

$ cd `port dir p5-graveyard`
$ cp p5-graveyard-withports.Portfile Portfile
$ port lint
Can't map the URL 'file://.' to a port description file ("can't set "version": can't read "replacements(
        write {
            foreach p $option_procs($optionName) {
                $p $optionName set [set $optionName]
            }
        }
        read {
            foreach p $option_procs($optionName) {
                $p $optionName read
            }
        }
        unset {
            foreach p $option_procs($optionName) {
                if {[catch {$p $optionName delete} result]} {
                    ui_debug "error during unset trace ($p): $result\n$::errorInfo"
                }
            }
            trace add variable $optionName {read write unset} option_proc_trace
        }
    )": no such variable").
Please verify that the directory and portfile syntax are correct.
To use the current port, you must be in a port's directory.

[larryv (Lawrence Velázquez)]

That attachment uses an old version of the graveyard; I made several changes a few days ago in r130161:130164.

[larryv (Lawrence Velázquez)]

latest graveyard

[larryv (Lawrence Velázquez)]

This​ seems to work for me.

[dbevans (David B. Evans)]

And me, thanks. The only minor improvement I can suggest is to include, at the head of the list, in comments, a copy of the command used to generate the list and maybe a date-time stamp as a help for maintainers not participating in this thread.

I will do some testing with this and let you know if anything else pops up.

[larryv (Lawrence Velázquez)]

Sounds good; I can commit whenever.

[dbevans (David B. Evans)]

Ran into something I didn't expect. Case in point is port p5-json-pp.

Currently a Portfile exists for p5-json-pp outside of p5-graveyard. After mojca's most recent trimming of subports, its only subport is p5.12-json-pp. The port only ever had subports < 5.14 since it is in core for more recent perl versions.

Before updating p5-graveyard to this latest test version, for historical reasons I had p5.10-json-pp installed.

After updating p5-graveyard and running portindex, I tried installing p5.12-json-pp and was successful even though p5-json-pp is in graveyard's list. I now see the following results.

$ port installed p5.*-json-pp
  p5.10-json-pp @2.273.0_0 (active)
  p5.12-json-pp @2.273.0_0 (active)

$ port outdated p5.*-json-pp
p5.10-json-pp                  2.273.0_0 < 2.273.0_1     

$ port info p5-json-pp (gets info from port p5-json-pp)
p5-json-pp @2.273.0 (perl)
Replaced by:          p5.12-json-pp
Sub-ports:            p5.12-json-pp

Description:          JSON::PP (no description available)
Homepage:             http://search.cpan.org/dist/JSON-PP/

Library Dependencies: p5.12-json-pp
Platforms:            darwin
License:              Artistic-1 GPL
Maintainers:          nomaintainer@macports.org

$ port info p5.10-json-pp (gets info from port p5-graveyard)
p5.10-json-pp @2.273.0_1 (perl)
Replaced by:          p5.16-json-pp

Description:          this port is only a stub and has been made obsolete by p5.16-json-pp
Homepage:             http://www.macports.org/

Platforms:            darwin
License:              unknown
Maintainers:          nomaintainer@macports.org

$ port info p5.12-json-pp (gets info from port p5-json-pp)
p5.12-json-pp @2.273.0 (perl)

Description:          JSON::PP (no description available)
Homepage:             http://search.cpan.org/dist/JSON-PP/

Library Dependencies: perl5.12
Platforms:            darwin
License:              Artistic-1 GPL
Maintainers:          nomaintainer@macports.org

I admit this is a pathological case. p5-json-pp should either be removed or updated to p5.16 - p5.20 (probably the latter due to the replacement by p5.16-json-pp offered by p5-graveyard). See #46343. But it looks like a Portfile with a subport < p5.16 can override p5-graveyard (at least sometimes). Is this what you expect?

[dbevans (David B. Evans)]

A possibly more relevant case. p5-test-tester has been replaced by p5-test-simple and has subports p5.10-p5.20.

It is not in the current graveyard list but is returned by the suggested list generation script so I assume it has been manually removed.

After adding the line

p5-test-tester					0.109.0_3

to p5-graveyard and running portindex

$ port info p5.10-test-tester (gets info from p5-test-tester)
p5.10-test-tester @0.109.0_1 (perl)
Replaced by:          p5.10-test-simple

Description:          this port is only a stub and has been made obsolete by p5.10-test-simple
Homepage:             http://www.macports.org/

Library Dependencies: perl5.10
Platforms:            darwin
License:              Artistic-1 GPL
Maintainers:          nomaintainer@macports.org

but

$ port info p5.8-test-tester (gets info from p5-graveyard)
p5.8-test-tester @0.109.0_3 (perl)
Replaced by:          p5.16-test-tester

Description:          this port is only a stub and has been made obsolete by p5.16-test-tester
Homepage:             http://www.macports.org/

Platforms:            darwin
License:              unknown
Maintainers:          nomaintainer@macports.org

Again where p5-test-tester and p5-graveyard have common subports, p5-test-tester is overriding.

[larryv (Lawrence Velázquez)]

Replying to devans@…:

But it looks like a Portfile with a subport < p5.16 can override p5-graveyard (at least sometimes). Is this what you expect?

It looks like the port index ends up with duplicate entries, and the one that comes last wins. Your examples come later alphabetically (“graveyard” < “json-pp” < “test-tester”), so they both override the graveyard, while I would expect that the graveyard would win out over something like “app-ack” (which I also excluded).

I was under the impression that duplicates in the index caused errors, so this surprises me. I don’t think there’s anything I can do about this in the graveyard, so we’ll have to weed out duplicates.

[larryv (Lawrence Velázquez)]

Fortunately, the only one I see locally is p5.12-json-pp.

[dbevans (David B. Evans)]

p5-json-pp marked obsolete, replaced by perl5.16 (core) in r130545, branches 5.8 5.10 5.12 included (#46343). Later branches never existed. To avoid conflicts p5-json-pp should not be included in p5-graveyard.

[larryv (Lawrence Velázquez)]

Updated script:

port -q info --index --line --version --revision --name 'p5-*' | awk '
    BEGIN {
        blacklist["p5-app-ack"] = ""
        blacklist["p5-catalyst-plugin-unicode-encoding"] = ""
        blacklist["p5-class-mop"] = ""
        blacklist["p5-email-mime-modifier"] = ""
        blacklist["p5-graveyard"] = ""
        blacklist["p5-json-pp"] = ""
        blacklist["p5-test-tester"] = ""
        blacklist["p5-test-use-ok"] = ""
    }
    {
        if ($3 in blacklist)
            next
        padding = (48 - length($3)) / 8
        if (padding != int(padding))
            padding = int(padding) + 1
        printf "%s", $3
        for (i = 0; i < padding; ++i)
            printf "\t"
        printf "%s_%d%s", $1, ($2 + 1), ORS
    }
'

Any other snafus?

[dbevans (David B. Evans)]

Looks like the following are about to become obsolete (#46342) so they are candidates for the blacklist

p5-vcp-autrijus-snapshot
p5-vcp-dest-svk
p5-vcp-source-cvsbk

In addition, there may be other outdated ports that need to be declared obsolete. I'm looking at the following where CPAN reports '410 Gone' in response to livecheck.

Error: cannot check if p5-csp was updated (The requested URL returned error: 410 Gone)
Error: cannot check if p5-eval was updated (The requested URL returned error: 410 Gone)
Error: cannot check if p5-file-slurp-unicode was updated (The requested URL returned error: 410 Gone)
Error: cannot check if p5-ifeffit was updated (The requested URL returned error: 410 Gone)
Error: cannot check if p5-innotop was updated (The requested URL returned error: 410 Gone)
Error: cannot check if p5-ipe was updated (The requested URL returned error: 410 Gone)
Error: cannot check if p5-pcsc was updated (The requested URL returned error: 410 Gone)

Finally, I'm thinking that any ports that are in the blacklist should be reviewed to make sure that they handle the dropped subports in addition to any other replacements they may specify.

[larryv (Lawrence Velázquez)]

Graveyard committed in r130773.

[mojca (Mojca Miklavec)]

Thanks a lot for all your effort in polishing out the graveyard port. Is there anything else left to be done before closing the ticket? Last time I checked the livecheck worked for all ports, but maybe somebody wanted to do extra checks on those ports?

One thing that comes to my mind would be opening tickets for ports that failed as listed in comment:29 (before we forget about those issues).

[dbevans (David B. Evans)]

Replying to mojca@…:

Thanks a lot for all your effort in polishing out the graveyard port. Is there anything else left to be done before closing the ticket? Last time I checked the livecheck worked for all ports, but maybe somebody wanted to do extra checks on those ports?

Yes, I fixed all the livecheck issues listed in comment:51. Only one was truly an obsolete port (p5-file-slurp-unicode).

One thing that comes to my mind would be opening tickets for ports that failed as listed in comment:29 (before we forget about those issues).

Good idea for those that don't already have a ticket or have been resolved already.

[dbevans (David B. Evans)]

I think #46379 is the only outstanding issue before perl5.8 through perl5.14 can, themselves, be removed.

[mojca (Mojca Miklavec)]

Ah, OK, I wasn't aware that we also planned to remove Perl versions themselves. Or rather: I don't see any urgency to do so (but honestly also no huge benefit in keeping them).

[dbevans (David B. Evans)]

Replying to mojca@…:

Ah, OK, I wasn't aware that we also planned to remove Perl versions themselves. Or rather: I don't see any urgency to do so (but honestly also no huge benefit in keeping them).

I just assumed that was where we were heading. They're not too useful without all the supporting extensions. perl5 would need some attention as well.

[mojca (Mojca Miklavec)]

There are other bits and pieces of the old Perl still around, like in git (#46570) for example, but also:

• ossp-uuid
• xraylib
• openbrowser

Related to that, biblatex-biber and intltool could use the PortGroup to create Perl variants rather than creating them manually.

[mojca (Mojca Miklavec)]

I'm closing this ticket. I consider the work done, even if the old versions of perl itself haven't been removed (yet?). But then again removing Perl itself is trivial enough.

If there are other things that need to be addressed, please point them out or open a new ticket.

[mojca (Mojca Miklavec)]

I removed the old variants from perl5 in r132928.