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