A new category of ports: purgatory

[Mojca Miklavec]

Hi,

Here's what the competing system is doing:
    https://github.com/Homebrew/homebrew-boneyard

Citation:

This repository contains formulae that were removed from other
repositories. Common reasons for retiring formulae to the boneyard
include lack of upstream maintenance or problems integrating with HB's
packaging requirements. Broken formulae are migrated here as an
alternative to allowing hard work and valuable knowledge to fade into
git history.

Mojca

On 18 October 2016 at 11:32, Mojca Miklavec wrote:
> 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