A new category of ports: purgatory

[Mojca Miklavec]

On 18 October 2016 at 10:42, Ryan Schmidt wrote:
> On Oct 18, 2016, at 2:53 AM, Mojca Miklavec wrote:
>
>> I would like to ask once again for thoughts about the following suggestion.
>>
>> 1.) Create a new folder/category called "purgatory" (other suggestions
>> for names welcome)
>
> I'm not in favor of moving ports to such a new category folder. You could add that as a secondary category without needing to move any files around. The question is, why?

There has been a lot of pressure from various developers to remove old software.

I mean, in theory p5.8-foo would probably still compile and work just
fine, but it causes extreme headaches and days of delay on the
buildbot. Plus problems when upgrading ports that would be stuck with
perl5.12 forever.

OK, so we moved all the old perl and python modules ports to
graveyard. But now we are getting requests to add some of them back.
(In order to have older versions of Python working some of the modules
indeed make sense.) And again pressure to remove that software as
well. Perl5.8 wasn't broken and people requested to add perl5.14 back,
perl5.16 up to 5.24 works just fine from what I know. I cannot decide
whether to keep it or to remove it. I don't have a problem maintaining
two extra versions and they don't hurt anyone. But there's constant
pressure to remove those. Putting them "aside" and making it easy to
add them back (while requesting a bit of extra steps from users) might
satisfy both groups.

I know that on Debian I can probably pick between two versions of gcc
or python, but certainly not more unless I make some special effort
and perform some additional steps to be able to do so.

>> 2.) We would put there any ports satisfying some of the following criteria:
>> - don't build at all
>> - abandoned upstream
>> - potentially maintainer upstream, but broken in MacPorts and require
>> a lot of further work before they are useful again
>> - apache 1, python < 2.7, python < 3.4, perl < 5.22, postgresql <
>> (something), ...
>>
>> 3.) For the time being I would only create a new folder and move those
>> ports there, but the idea is to actually stop indexing those ports and
>> stop building them on the buildbots. (Or perhaps index them, but when
>> users request them, tell them that the port is in purgatory and point
>> them to instructions what to do.) This is something that can always be
>> implement later.
>
> Why would you stop indexing them?
>
> Why would you have the buildbot stop building them?

There are certain groups of ports that are simply there for no good
reason. They might have worked 10 years ago, but no longer even
compile. I'm always afraid to delete them though because that takes
quite some research and you never know whether a port is useful to
some people or not. If we had a special group, I would take the task
more "lightheartedly" and just move those ports aside. And if nobody
complains for a long while, potentially remove them. Many ports also
give false impression that they are supported. Users try to install
it, it fails, there's no maintainer, nobody willing to take a look at
the ticket ... people might just as well leave MacPorts because of
frustration. A special category would at least make it clear "here you
have the port, we know it's broken and there was nobody around to fix
it, but if you want to use it and if you are willing to take some
effort to fix it yourself, you can start where others left".

As for why the buildbot would not build old Pythons and Perls, I have
no clue. In fact I'm mixing a lot of different categories of ports
together and all the rules don't make sense for everything that I put
into the mixture.

But not having broken ports in index would certainly avoid confusion
for users. As a newbie I would be way more frustrated to see the build
break (and not see any progress at all) than not to see my favourite
software listed at all.

I don't like the fact that we have so many different kinds of failures
and we find it difficult to find the most critical ones ourselves.

> What would the instructions that you suggest to point the user at say?

A clear message that says something in the following sense (not
literally of course and a bit depending on the reason why the port
ended up there in the first place): "Look, this is some software that
you can use at your own risk; you need to do at least this and that to
confirm that you really want to use that older software and so that
you confirm that you know you might be on your own. If it works for
you, fine, we are glad that we could help you. But if it fails, either
send us a patch, or don't complain too loud (we don't want to keep a
ticket open for another 10 years that nobody is interested in fixing).
If you believe that the port ended up here by accident and that it
should get full support again – if it works and you find it super
useful, feel free to tell us that. If it's broken and you know how to
fix it, we might also consider adding it back."


>> 4.) If any users start crying after we have removed perl5.20, they can
>> get it from the purgatory without playing a detective (but they have
>> to manually add it to PortIndex). If some project that is being
>> actively developed upstream, but is badly supported and broken in
>> MacPorts, users might easily find the existing broken files and fix
>> them again.
>>
>> 5.) Officially those ports would be completely unsupported (but, if
>> for some reason, some enthusiast really wants to fix a problem in gcc
>> 1.0, I would not prevent them from doing that).
>>
>> I would find it much easier to move the port there than to keep asking
>> everyone around whether it's ok to remove that port that hasn't been
>> building for the last 7 years.
>>
>> I would like to clear this up ASAP. Because I would want to move the
>> old Perls there (once I delete it, I will no longer be willing to
>> resurrect it, but I would be willing to give it that last breath and
>> put it to "purgatory" now). I would like to point people to something
>> they can do easily if we remove those old ports, but at the same time
>> there has been a lot of pressure to actually remove those ports. I
>> just find it super confusing that we insist in keeping some ancient
>> software and remove the other. It would be better to have some clearer
>> policy for the whole macports.
>
> What's the harm if I personally wish to continue providing older php ports? If others no longer wish to provide older python ports that's up to them to decide. All software is different; I don't need a unifying MacPorts policy to dictate which software is too old.

A policy that says "maintainer is the boss and gets to decide when to
retire old ports" is still better than no policy at all.

At the moment I constantly find myself in the middle of flame wars of
whether or not to keep supporting old software like perl. I would
prefer "a greater authority" to help me decide when to cease support,
so that I know which ticket to close as "wontfix" - the one requesting
removal or the one requesting adding the ports back :) :) :)

But independent of old perl/python/clang/gcc/apache/php/... policy, I
would again like to stress that I would want to have some special
department for old and most likely useless ports. Like software that
depends on wxWidgets 2.8 and will never get ported to 3.0 (with
potentially zero users).

Mojca