Quoting Steve Litt (slitt@???):

> Nope. My volunteering these days is difficult, much more important than
> any Linux distro, and not bothered with by about 98% of the population
> to which it's crucial. I'm blowing off time I really should be working
> to do this volunteerism, and have no remaining time to learn
> package-managership and then herd all the cats into accepting my
> packaging solutions.

Hmm. The low-hanging fruit would be to provide a list of POSIX-relevant
packages omitted by default from a default install by ISOs of interest.
This would make it easy for someone to make a virtual posix-tools
package consisting of a bunch of Depends references to the individual
real packages required.

I'm still not convinced this is a problem needing addressing. You know
why the Linux kernel never implemented the full POSIX.1 suite's
requirements in kernelspace? That was because Torvalds knew how Unix
bureaucrats worked: Every time, during early Linux history, someone put
pressure on the kernel team to support all of POSIX.1, Torvalds pushed
back and said 'Tell you what. Show us what real software is breaking
for lack of support for some syscall or other, and we'll see what can
be done. In this fashion, the kernel team developed kernel support code
only for the subset of POSIX.1 _actually in use_, instead of earning
buzzword compliance just to satisfy some academic committee's wishlist.
What resulted was, well, something with agility and performance, i.e.,
not Solaris.

I believe this remains the kernel team's attitude to POSIX, to this
day: "I'm sorry, but what real problem are you saying requires
solving?"

On a OS-system level, IMO, there's a limit to which it makes sense to
address the 'Some guy hasn't yet figured out apt-get' by increasing the
size of an ISO's default installation.