1. This code has no maintainers. 2. It's a leaf package 3. Upstream has been dead since 2008. 4. It has many build bugs: https://bugs.gentoo.org/830598 https://bugs.gentoo.org/871303 https://bugs.gentoo.org/885877 https://bugs.gentoo.org/897946 https://bugs.gentoo.org/945041 5. It's build system hard-codes ar and ranlib. https://bugs.gentoo.org/725160 https://bugs.gentoo.org/725218 6. It's build system is too clever by half and consists of makefile and helper scripts that re-implement build-in make functionality in weird, weird way, e.g. compile script that's generated, you cat executable name and CFLAGS into file conf-cc, a helper script reads first line of that file, prefixes it with exec, echoes it into a new script and makes said script executable. 7. I do not trust this code. It was written by someone who thought he was too clever by half. There are at least eight Duff Devices, re-implementing memcmp, bzero, memcpy and other library functions. There's weird wrapper around malloc that tries to ensure alignment. There's realloc that always copies memory to new, larger place. All of them take char*. All of them are K&R C-declared. Why would you do that? 8. There are replacements, chief among them are actual xinetd and GNU inetutils that had release this year. See virtual/inetd for full list. Reproducible: Always
(In reply to NHO from comment #0) > 1. This code has no maintainers. Classic djbware, though in this case, smardenware I guess. > 2. It's a leaf package Ditto. > 3. Upstream has been dead since 2008. Ditto, though in djb's case it is sometimes more complicated because he e.g. never actually wrote any code at all for "redo", just notes on how it is "supposed" to work lmao. > 4. It has many build bugs: No djbware, nor software from people who worship him, is ever complete without many build bugs! > 5. It's build system hard-codes ar and ranlib. ... like this classic one. > 6. It's build system is too clever by half and consists of makefile and > helper scripts that re-implement build-in make functionality in weird, weird > way, ... or this one, which is what I also call a classic build bug. :D > 7. I do not trust this code. It was written by someone who thought he was > too clever by half. There are at least eight Duff Devices, re-implementing > memcmp, bzero, memcpy and other library functions. There's weird wrapper > around malloc that tries to ensure alignment. There's realloc that always > copies memory to new, larger place. All of them take char*. All of them are > K&R C-declared. Why would you do that? The cult of djb defies explanation, do not ask. :D Anyways yes, let's do this.
