Turns out to be relatively easy to move RPM payload handling. I'd
forgotten what (and how) I implemented fsm.c back in ~2002.

There's still some modest refactoring that needs to be done in iosm.c  
with
the rpmtsNotify() call back, and various bitfields that control
payload unpacking, but none of that will be very hard to achieve.

Perhaps the most unusual part of the refactoring will be
     #define _RPMFI_INTERNAL
     #define _RPMFI_NOMETHODS
     #include "../lib/rpmfi.h"
to share the internals of a rpmfi object without any opaque getters/ 
setters methods.

(aside) rpmfi has always been a garbage dump of various and sundry  
control
fields that really should be moved (mostly anyways) into a rpmte object.
I'll get to the rpmfi -> rpmte refactoring, which also goes quite  
deeply into rpmbuild, eventually,
just not today.

However I see no reason not to continue eliminating lib/fsm.c in favor
of using rpmio/iosm.c. If nothing else, the change will clarify the  
differences
between a "package" and an "archive", and how/where each is handled
within RPM.

In order to add a "make check" for payload unpacking automated QA, I'm
now questing for a LGPL compatible tar(1) (or other archive CLI tool)  
that I can
port on top of RPM payload unpacking.

I suppose stealing a copy of pax.c code is an unsurprising choice.  
But perhaps
there's another/better/simpler choice, maybe the *BSD tar  
implementation? that
I'm unaware of.

All I'm really looking for is a tar.c with a sufficiently rich and  
complete set
of tar(1) CLI options already implemented. Porting to use popt  
instead, much like I have
done with rpmgrep and rpmdigest, is rather straightforward coding.

Any suggestions for a LGPL-compatible tar(1) implementation other  
than PAX?

73 de Jeff