On Fri, Oct 10, 2014 at 09:22:18PM +0000, Robin H. Johnson wrote:
> On Sun, Sep 28, 2014 at 12:31:16PM -0400, Richard Yao wrote:
> > May I suggest an alternative? We could implement sys-virtual/posix and
> > make it depend on all packages that are not necessary for @system, but
> > are necessary for proper POSIX compliance. Then we can tell users who
> > need/want an environment containing all tools specified by POSIX, such
> > as those not using sys-kernel/*-sources, to `emerge virtual/posix`.

kernel-sources doesn't get you that afaict: it just gets you bc. Certainly
doesn't get you ed, which is tiny and designed to be used in rootfs.

I just don't see the point in not providing a POSIX.2 system by default.
It feels like crippling the distro before it's out the door.

> I like this idea, for a virtual/posix; would let us trim a lot of other
> things from some environments.

Such as?

Not arguing with your use-case. Just wondering why ed and bc are considered
such major burdens, but polkit+systemd+udev+dbug+glib+glibc+godknows are a
minimal base.

I feel like I've gone through the looking-glass. (pam pulling in polkit?)

Anyhow, it seems to that in the minimal embedded env you're talking about,
the user can quite easily remove or package.provide things, and that
can be done in the profile as well as myriad other options for the expert
use-case; none of which speak to the default.

We used to have LDAP enabled by default, for the best part of a decade
to my recollection, just so that people could plug a disk into a Windows
environment, on the grounds that this made us look more "professional."
With respect, nothing looks more amateurish than a *nix that doesn't even
comply with POSIX.2.

It's not exactly hard, yet we don't manage it, but meantime let's add in
massively complex layers. It seems very masochistic sometimes, from an
external perspective. Loads of extra work, discussion and what often
reads like heartache, for want of a better word, in order to achieve what
you could have done really simply.

Still, moar code must be better, right?

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Reply via email to