Are broken ports retested before performing scheduled removal?

[Stefan Eßer]

Am 16.05.20 um 10:44 schrieb Stefan Ehmann:
> On Thursday, May 14, 2020 1:24:17 AM CEST Edward Sanford Sutton, III wrote:
>>   games/oneko was recently removed as it was marked broken due to being
>> unfetchable. I tried an old copy of the ports tree I had where it was
>> marked as such and `make fetch -DTRYBROKEN` succeeded. Was there an
>> error recorded for this and was it ever retested? Is this just a side
>> effect of having a failure and no maintainer?
>>   If being removed as unfetchable, wouldn't a better MOVED entry be to
>> say it was unfetchable (for more than 6 months) instead of just broken
>> for more than 6 months?
>> Thanks for feedback
> 
> I've recently asked myself the same question:
> 
> multimedia/gpac-mp4box is flagged
> BROKEN=unfetchable
> DEPRECATED=Broken for more than 6 months
> 
> multimedia/gpac-libgpac uses the same distfile from the same mirror and is not
> marked broken.
> 
> I figured once a port is marked unfetchable, it will be deleted, even it is a
> transient failure. Of course, unless someone opens a bug report.

I have also had to resurrect ports that had been deleted as unfetchable
(and which were prerequisites of ports I was working on) and found that
they were either available from the MASTER_SITE given in the port (i.e.,
have most probably been only temporarily unavailablet) or had been moved
to Github (or some other repository) and now have better accessibility
than before, after an update of the ports' master sites.

IMHO, it shows disrespect to the creator or maintainer of a port, if it
is marked broken and deleted, in such a case, especially since there is
no guarantee that the maintainer receives a notification for ports
marked broken (for any reason, often easily fixed, but noted only when
the port is deleted if the maintainer has no need to update or rebuild
it during the time of deprecation).

Regards, STefan