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
