Remove *-graveyard ports

[jmroot (Joshua Root)]

These cause hundreds of ports to be reindexed every time one subport is added (or removed), which takes quite some time. And more importantly, they don't provide any real useful function: marking a module installed for one interpreter version as replaced_by one installed for a different interpreter version doesn't provide a convenient upgrade path at all, because the two don't install the same files. Manual intervention is needed just as if the subport were simply deleted. So the goal of avoiding buildbot failure messages is better achieved by doing just that.

[ryandesign (Ryan Carsten Schmidt)]

I have not been certain whether the graveyard ports are useful. Maybe you're right that they're not.

[mojca (Mojca Miklavec)]

I understand the pain being present with the python graveyard ports. For perl we try to keep this minimal and only update the graveyard once or twice per year which seems like a reasonable compromise to allow getting rid of the gazillion of no-longer-existing subports.

Also, perl is somewhat special in the way that we do have the perl5 port, so to some extent and with quite a bit of limitations the intention does work to some extent (when we upgrade perl5 to use a newer version and remove the old variant, and if we removed the old subports at the same time, modules that previously worked with perl might keep working). So maybe this is a plea to keep the p5-graveyard if you happen to decide to remove the other one.

For python ... could we at least provide a mechanism to remove old ports? I agree that the py-graveyard has very very limited usability, and by constantly updating it just for the sake of one port at a time, given the waaaaaaay to long parsing time of the file, it's a bit of annoyance.

[reneeotten (Renee Otten)]

I agree that the py-graveyard isn't all that useful... and would be fine with "just" removing subports as needed, without giving any replacement rules. That would certainly make the removal of EOL Python versions a much less time-consuming task.

In the meantime, I cleaned up the py-graveyard file by removing all entries that have been in there for more than 1 year; this should help quite a bit with the reindexing time... see ​PR5383

[jmroot (Joshua Root)]

In e4a42da6a4abc7fce9a20c557d57d01d376290be/mpbb (master):

sort-with-subports: exclude ports known to fail

References: #59051

[jmroot (Joshua Root)]

There, the graveyard ports no longer have any reason to exist. :)

If replacement is desired, it can be done in the individual portfiles.

[jmroot (Joshua Root)]

Replying to mojca:

could we at least provide a mechanism to remove old ports?

port uninstall obsolete will remove them, as will port reclaim if they have no requested dependents. What more do you want?

[reneeotten (Renee Otten)]

In 006a4c24f521a8ea4a293cf6a8714a7e1f0848f6/macports-ports (master):

py-graveyard: purge entries that are more than one year old

Remove entries in that have been present for more than one year,
compared to py-graveyard/Portfile at commit 754246c (30Sep2018).

We typically purge obsoleted ports after one year, so there is no reason
to leave the replacement rules in place for longer than this.

See: #59051

[jmroot (Joshua Root)]

As the only objections seem to have been addressed, I'm going to go ahead with the removal.

[mojca (Mojca Miklavec)]

Joshua, can you please provide an example patch or Portfile for how I should modify a p5-<something> port when I want to declare p5.26-something obsolete (with or without replacement)?

[jmroot (Joshua Root)]

subport p5.26-something {
    replaced_by p5.30-something
    PortGroup obsolete 1.0
}

It shouldn't be hard to add a new option like perl5.obsolete_versions to the perl5 portgroup to automate this if you want.

[reneeotten (Renee Otten)]

Joshua, sorry but from that change to mpbb it's not clear to me how one would proceed now with, for example, Python subports.

I get that you're suggesting to do the replacement if required in the actual Portfile; that's fine with me (anyway that's not very useful, so that can likely be skipped in most cases). What do we do know when one just want to remove a subport, then I would need to add the code below to the Portfile?

subport p34-something {
    PortGroup obsolete 1.0
}

If so, that hardly makes the removal of subports easier... or am I missing something?

[jmroot (Joshua Root)]

In 1f65d2919352023f4662f1bf9f8023c29b57e2cd/macports-ports (master):

Retire graveyard ports

Closes: #59051

[jmroot (Joshua Root)]

Replying to reneeotten:

I get that you're suggesting to do the replacement if required in the actual Portfile; that's fine with me (anyway that's not very useful, so that can likely be skipped in most cases). What do we do know when one just want to remove a subport, then I would need to add the code below to the Portfile?

subport p34-something {
    PortGroup obsolete 1.0
}

If so, that hardly makes the removal of subports easier... or am I missing something?

If there's no replacement, simply delete 34 from python.versions.

[eborisch (Eric A. Borisch)]

If you have a chance, take a look at ​https://github.com/macports/macports-ports/pull/5598 (implementation of python.obsolete_versions.)

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In 74f6738c84de2db5789c674cf7c19e4f037bd34c/macports-ports (master):

dbus-python: remove subport for Python 3.4

Do not use replaced_by.
See #59051 for discussion.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In fcf55e8985d7aabe259ff6555f3d06509978f764/macports-ports (master):

py-pykde4, py-pyqt4: remove subports for Python 3.4

py34-pykde4 and py34-pyqt4 depend on nonexistent port dbus-python34.

Do not use replaced_by.
See #59051 for discussion.

Fixes #59891

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In fcf55e8985d7aabe259ff6555f3d06509978f764/macports-ports (dar, master, py38-reproject, revert-6945-rust-1.43.0, wireshark):

py-pykde4, py-pyqt4: remove subports for Python 3.4

py34-pykde4 and py34-pyqt4 depend on nonexistent port dbus-python34.

Do not use replaced_by.
See #59051 for discussion.

Fixes #59891