Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#46322 closed enhancement (fixed)

p5-*: consistently remove Perl versions 5.8-5.14

Reported by: mojca (Mojca Miklavec) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: dbevans (David B. Evans), ryandesign (Ryan Carsten Schmidt), larryv (Lawrence Velázquez)
Port:

Description

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, ...

Attachments (6)

remove-perl-branches.py (1.1 KB) - added by mojca (Mojca Miklavec) 9 years ago.
A script to remove perl branches p5.8-5.14
remove-p5.8-5.14.diff (496.6 KB) - added by mojca (Mojca Miklavec) 9 years ago.
A diff with Perl branches 5.8-5.14 removed
p5-obsolete.Portfile (704 bytes) - added by mojca (Mojca Miklavec) 9 years ago.
Initial attempt to create a Portfile collecting all obsolete ports
p5-graveyard.Portfile (1.5 KB) - added by larryv (Lawrence Velázquez) 9 years ago.
suggested Perl graveyard
p5-graveyard-withports.Portfile (60.8 KB) - added by mojca (Mojca Miklavec) 9 years ago.
Portfile (36.7 KB) - added by larryv (Lawrence Velázquez) 9 years ago.
latest graveyard

Download all attachments as: .zip

Change History (66)

Changed 9 years ago by mojca (Mojca Miklavec)

Attachment: remove-perl-branches.py added

A script to remove perl branches p5.8-5.14

Changed 9 years ago by mojca (Mojca Miklavec)

Attachment: remove-p5.8-5.14.diff added

A diff with Perl branches 5.8-5.14 removed

Changed 9 years ago by mojca (Mojca Miklavec)

Attachment: p5-obsolete.Portfile added

Initial attempt to create a Portfile collecting all obsolete ports

comment:1 Changed 9 years ago by 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.

Changed 9 years ago by larryv (Lawrence Velázquez)

Attachment: p5-graveyard.Portfile added

suggested Perl graveyard

comment:2 in reply to:  1 Changed 9 years ago by larryv (Lawrence Velázquez)

Something like this.

comment:3 Changed 9 years ago by 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?

comment:4 in reply to:  3 Changed 9 years ago by 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

    old new  
    1616
    1717proc unknown args {
    1818    upvar 1 replacements replacements
     19    if {[llength $args] < 3} {
     20        lappend args 5.8 5.10 5.12 5.14
     21    }
    1922    foreach series [lassign $args port vers] {
    2023        lassign [split $vers _] ver rev
    2124        if {$rev eq ""} {
     
    3033    }
    3134}
    3235
    33 io-tty                              1.120.0_1       5.8  5.10 5.12 5.14
    34 wx                                  0.992.300_3     5.8  5.10 5.12 5.14
     36# SUBPORT (without "p5*-" prefix)   VERSION+REV     REPLACED SERIES (optional)
     37io-tty                              1.120.0_1
     38wx                                  0.992.300_3
    3539
    3640if {${subport} ne ${name}} {
    3741    PortGroup obsolete 1.0

comment:5 in reply to:  3 Changed 9 years ago by 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?

comment:6 Changed 9 years ago by 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?

comment:7 in reply to:  6 ; Changed 9 years ago by 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.

Last edited 9 years ago by larryv (Lawrence Velázquez) (previous) (diff)

comment:8 in reply to:  7 Changed 9 years ago by 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.

comment:9 Changed 9 years ago by 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.)

comment:10 Changed 9 years ago by 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.

Last edited 9 years ago by mojca (Mojca Miklavec) (previous) (diff)

comment:11 Changed 9 years ago by 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.

comment:12 in reply to:  9 ; Changed 9 years ago by 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.

comment:13 in reply to:  12 ; Changed 9 years ago by 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?

comment:14 in reply to:  10 Changed 9 years ago by 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.

comment:15 in reply to:  11 Changed 9 years ago by 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.

comment:16 Changed 9 years ago by 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 ;)

comment:17 in reply to:  13 ; Changed 9 years ago by 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
%

comment:18 Changed 9 years ago by 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.

comment:19 in reply to:  17 ; Changed 9 years ago by 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

comment:20 in reply to:  18 Changed 9 years ago by 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.

comment:21 in reply to:  19 Changed 9 years ago by 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.

comment:22 in reply to:  16 ; Changed 9 years ago by 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?

comment:23 Changed 9 years ago by 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 ...)

comment:24 in reply to:  22 Changed 9 years ago by 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).

comment:25 Changed 9 years ago by 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

Changed 9 years ago by mojca (Mojca Miklavec)

comment:26 Changed 9 years ago by 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.

comment:27 Changed 9 years ago by mojca (Mojca Miklavec)

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

Last edited 9 years ago by mojca (Mojca Miklavec) (previous) (diff)

comment:29 Changed 9 years ago by 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
Last edited 9 years ago by mojca (Mojca Miklavec) (previous) (diff)

comment:30 Changed 9 years ago by 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?

comment:31 Changed 9 years ago by 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.

comment:32 Changed 9 years ago by 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.

comment:33 in reply to:  27 Changed 9 years ago by 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.

comment:34 in reply to:  23 Changed 9 years ago by 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.

comment:35 in reply to:  27 Changed 9 years ago by 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.

comment:36 Changed 9 years ago by larryv (Lawrence Velázquez)

Cc: larryv@… added

Cc Me!

comment:37 Changed 9 years ago by 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.)

comment:38 in reply to:  37 ; Changed 9 years ago by 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”?

comment:39 in reply to:  38 Changed 9 years ago by 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.

comment:40 Changed 9 years ago by 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.

comment:41 in reply to:  40 Changed 9 years ago by larryv (Lawrence Velázquez)

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

Changed 9 years ago by larryv (Lawrence Velázquez)

Attachment: Portfile added

latest graveyard

comment:42 in reply to:  40 Changed 9 years ago by larryv (Lawrence Velázquez)

This seems to work for me.

comment:43 Changed 9 years ago by 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.

comment:44 in reply to:  43 Changed 9 years ago by larryv (Lawrence Velázquez)

Sounds good; I can commit whenever.

comment:45 Changed 9 years ago by 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?

comment:46 Changed 9 years ago by 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.

comment:47 in reply to:  45 ; Changed 9 years ago by 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.

comment:48 in reply to:  47 Changed 9 years ago by larryv (Lawrence Velázquez)

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

comment:49 Changed 9 years ago by 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.

comment:50 in reply to:  49 Changed 9 years ago by 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?

comment:51 Changed 9 years ago by 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.

comment:52 Changed 9 years ago by larryv (Lawrence Velázquez)

Graveyard committed in r130773.

comment:53 Changed 9 years ago by 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).

comment:54 in reply to:  53 Changed 9 years ago by 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.

comment:55 Changed 9 years ago by dbevans (David B. Evans)

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

Last edited 9 years ago by dbevans (David B. Evans) (previous) (diff)

comment:56 Changed 9 years ago by 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).

comment:57 in reply to:  56 Changed 9 years ago by 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.

comment:58 Changed 9 years ago by 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.

Last edited 9 years ago by mojca (Mojca Miklavec) (previous) (diff)

comment:59 Changed 9 years ago by mojca (Mojca Miklavec)

Resolution: fixed
Status: newclosed

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.

comment:60 Changed 9 years ago by mojca (Mojca Miklavec)

I removed the old variants from perl5 in r132928.

Note: See TracTickets for help on using tickets.