How to discontinue ports completely (py26 deprecation) ...

[Mojca Miklavec]

On 15 August 2016 at 03:52, Fred Wright wrote:
> On Sat, 13 Aug 2016, Christopher Jones wrote:
>>
>> I agree there is no way to migrate completely to 3.x, but I am still not
>> really convinced keeping both the 2.6 and 2.7 versions in MacPorts is
>> worth the effort. 2.6 needs to be dropped sometime...
>
> Given that the effort involved in keeping it is zero, and the effort
> involved in removing it is nonzero, I don't think the "effort" argument
> really flies.

One of the reasons for keeping support for 2.6 for me was the ability
(= hack) to keep both wxPython 2.8 and 3.0 installable side-by-side
(for example as py27-wxpython-3.0 and py26-wxpython-2.8).

See:
    https://trac.macports.org/ticket/46351

But then again:
- this has been a known problem since the release of Lion (if not Snow
Leopard), more than five years ago
- there are currently exactly three ports affected:

  - py-dsv: a port which I plan to delete at some point (unless
someone has a strong objection)

  - grass: which is semi-broken anyway and I would be surprised if we
actually have any real users; not to misunderstand me, the software
seems great, but there's currently almost no manpower to fix our
*port* properly; and maybe wxPython 3.0 works better by now, who knows

  - py-robotframework-ride: maintained both upstream and in MacPorts;
but the upstream had the ticket open for almost 5 years and didn't
manage to do anything else beyond labelling the ticket as "high
priority"

I would like to get rid of py-wxpython-2.8 at some point. I don't want
to spend any effort in case it no longer compiles on the latest OS,
but if it requires zero effort to keep it there for the sake of one
port, so let it be.

I would no longer oppose the removal of py26-wxpython-2.8 though.

-----------------------

On a related note. It would be nice to establish a common policy about
the old software versions that are in principle still usable (and
potentially useful for MacPorters wishing to test their software
against those old software, but not of "general interest" / for the
sake of just being able to run software X that depends on
python/perl/whatever).

That includes perl5.8 - 5.20, python up to 2.6 and 3.3, ...

If I remember correctly, Homebrew split their collection of formulas
into several repositories. If MacPorts did something similar, we could
have a special repository for "abandonware", potentially in multiple
categories. That could include:

- ancient version of ruby, perl, python, apache, qt3, ...
- wxWidgets 2.8 (once we get rid of it as a dependency of other
software packages)
- ports that are no longer maintained upstream, have no maintainer in
macports, and might even be broken
- ports that could potentially work, but have no maintainer and need work
- ...

The benefits include:
- cleaner central collection of ports with less old crapware
- it would be easier to move a port to that special repository than to
remove the port altogether (I'm always reluctant to delete ports even
if I suspect that they are useless, but one never knows whether other
people use the software and are not subscribed to our mailing lists)
- it would be easier for users to find and install that software if they need it
- we could get a clear message to the users, saying that "maintainer
is needed" if they want the software to be improved
- no need for long discussions about whether apache1, perl5.20,
python26, ... should still be available or not: simply move them to
the other repository
- tickets could be opened, but would automatically be assigned lower
priority and some kind of message (we accept patches, but don't blame
anyone if nobody fixing this)
- buildbot could be configured to either build all the ports without
sending any emails about failures, or perhaps not build them at all

Mojca