Orphaned dependents from py-matplotlib update

[jmroot (Joshua Root)]

The update to 1.2.0 (r99786) and consequential removal of py24/py25 subports in r99788 left the following ports with a nonexistent dependency:

py25-astlib
py24-nltk
py25-nltk
py25-psychopy
py25-pyml
py25-scitools
py25-aplpy
py25-kapteyn
py25-pyregion

Either the dependents need to be removed too, or the dependencies need to be brought back at an older, copmpatible version. (Or, I suppose if matplotlib is optional in some cases, the dependency could just be removed.)

[stevenbird1@…]

I would be happy if someone could remove matplotlib as a dependency for py24-nltk and py25-nltk please.

[robitaille@…]

I'll fix the dependencies or remove the ports (depending what can be done) for astlib, aplpy, kapteyn, and pyregion, since I added those. In the long term, how long do we envisage maintaining Python 2.4 and 2.5 and associated ports? Is there a way to find out how many users are actually making use of these?

[jmroot (Joshua Root)]

Replying to stevenbird1@…:

I would be happy if someone could remove matplotlib as a dependency for py24-nltk and py25-nltk please.

r102450

[jmroot (Joshua Root)]

Replying to robitaille@…:

In the long term, how long do we envisage maintaining Python 2.4 and 2.5 and associated ports?

For the modules, I'd generally just remove the old python versions when upstream (the module's) drops support for them. (Though making sure to take care of dependents first, so this kind of ticket doesn't happen.) Where that hasn't happened, it shouldn't be much of a maintenance burden if the unified portgroup is used.

Last time we suggested dropping python24, some users still needed it. We should probably ask again in the not too distant future, since it's no longer getting security updates, and if nobody needs it we're better off getting rid of it so nobody accidentally uses an exploitable version. That should again happen from the top down, deleting dependents or moving them to a newer python version before deleting their dependencies.

Is there a way to find out how many users are actually making use of these?

We could probably analyse the logs from packages.macports.org. Though that only tells you how many have been downloaded in any given period, not how many users have them installed. (It's also geographically biased.)

[petrrr]

Cc Me!