This disparity comes up fairly often. As an example, some
folks have done a lot of good (in the sense of being useful)
work getting various GNU things working on Plan 9 as pre-
requisites for things they want. It'd be nice if these were
available as an "import package" for folks to use who just
want some random linux program.

The complete set of dependencies is obviously gigantic, ever-
growing, and infeasable, but getting some useful subset is
a different story. In fact, if you look through contrib (by
which I mean fgb's very nice packaging system), we already
have a nice subset.

Some folks doing this work - and more watching - have
argued that this should all be dumped into APE. I think this
would be bad. I've used APE for exprt as much as import
(although, honestly, I've gotten somewhat lazy recently and
have started making p9p a pre-requisite), and being able to
check code against a "least common denominator" is very
helpful. One might argue that APE's current denominator is
too low (some of the things we require defines for and treat
as extensions have since become incorporated into ANSI and
POSIX), but that's really an independent discussion. There
remains a real difference between ANSI/POSIX standards and
GNU (or whoever) random gunk.

APE's export filter is very useful, and would be missed, but
there's an equally valid import role that it isn't very good at
serving, in modern contexts. I'd rather see that broken out
into a distinct environment, say G(nu)APE.

Of course, back on the question which prompted all this,
there remains an interesting question: do we duplicate the
library, or have it behave differently depending on where
it's used? Adding stuff in for the import environment is
relatively easy (in terms of organization and conflicts), but
should our stdio library really need to know whether it's being
used for import or export?

Anthony