Interix HEADS UP: maintainence help needed

["Todd Vierling" <tv%netbsd.org@localhost>]

I can't maintain the Interix infrastructure myself anymore for reasons
I can't explain in a single paragraph.  That said, I will attempt to
keep up with things and do an occasional bulk build, but I can't
devote nearly the same amount of time I once did to maintenance of
Interix support.

If you're interested, please let me know via a direct reply; I'm no
longer subscribed to pkgsrc-users.

There are several things that need work -- my long-rotted TODO list --
specifically:

* Windows Server 2003 R2 (SUA 5.3) and Windows Vista (SUA 6) support.
I have no machines running either of these OS's, so I can only provide
Interix 3.5 binaries that should run fine under shlib backwards
compatibility under SUA.  There may or may not be special support
needed to make packages compile directly on these SUA versions, but
someone has to step up and try it out.

* sysutils/user_interix.  It works, sort of.  Windows is Special in
that a user and group cannot share exactly the same name; for that
reason, packages that use identical user and group names (e.g.
mailman:mailman) trigger an error in mk/platform/Interix.mk.  However,
users and groups are mostly interchangeable in POSIX file permissions
under Interix; for that reason, it may be possible to make some
packages create only a group ID (which can be specified as the "user"
part of filee permissions), and others may need special, separate user
and group IDs.

* JVM support ("would be nice").  I scuttled lang/win32-jdk, which was
promising -- it was a wrapper around a Windows-based JDK install --
but needs a lot of help to get it running for real.

* Support for <inttypes.h> or <stdint.h>.  These are missing on
Interix 3.5 (though may exist under SUA), but many packages have
patches to work around that fact.

* A replacement *scanf() is needed to make some things, e.g. libIDL,
work properly.  It parses, but does not decode, 64-bit ints properly.

* vfork() leaks because of a never fixed bug in the POSIX subsystem.
Packages that use it may want a regular fork() based approach.

* Interop Systems' libport may be useful, but it supplies (IMHO) way
too much, and overrides some C preprocessor level assumptions that
pkgsrc makes about Interix in order to make packages work *without*
the extra glue.  libport was BSD licensed at one point, but it is now
unfortunately closed source and restrictively licensed.

--
-- Todd Vierling <tv%duh.org@localhost> <tv%pobox.com@localhost> 
<todd%vierling.name@localhost>