On 12/29/18 9:24 PM, A. Wilcox wrote:
> system/at
>
> * does not work at all
>
> Proposed action: find a different implementation of at(1) if possible
I'm not aware of any alternate implementations. I'm not sure how
frequently people actually use at(1), but I haven't seen people ask
about it except for a handful of times in all my years on IRC. We might
be able to get away with not shipping it for now. Otherwise, it looks
like our only option is to patch it and make it work.
> system/busybox
>
> Proposed action: rm -r with extreme prejudice
I see no reason to keep it. It might make sense to move to legacy/ or
user/ or an active volcano.
> system/fcron
>
> * untested
>
> * some vague reports that it doesn't work
>
> Proposed action: see if it works, if not, move to legacy/
I don't see any reason why fcron wouldn't work besides maybe
incompatibility with musl. Alternatively, we could switch to another
cron implementation like cronie.
> system/fortify-headers
>
> * causes build failures and ICE on valid code on x86_64 and arm64
>
> * does not even work / function at all on ppc64 ppc32 or armv7
>
> Proposed action: rm -r
If there's nothing that depends on it, I'm fine with removing it.
> system/gcc
>
> * Go support is broken on ppc64 (segfault)
>
> * Go support doesn't compile on pmmx (uapi header issue)
>
> * Ada support is broken on arm64, possibly others
>
> Proposed action: remove Go and Ada support from Adélie
Go is a pretty popular language, so I think in the long term we will
need to have at least one Go compiler working. We already don't support
the reference implementation because of its poor architecture support,
and I don't see that situation ever changing. I'm fine with omitting Go
from GCC in 1.0, but we should figure out a fix before 2.0. It sounds
like it's going to be easier to fix than Ada.
I'm less concerned about dropping Ada since it's not as widely used as
Go. But we should eventually support it too.
-Lee
Received on Sun Dec 30 2018 - 04:23:16 UTC