Hi, 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) 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. 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. Mojca _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
