Call for testing: patch-o-matic-ng

Hi!

I've now gotten patch-o-matic-ng to a state where it is actually quite
useable.  

Everybody interested can check it out from CVS
(netfilter/patch-o-matic-ng).  Everything should look exactly like the
old patch-o-matic, including screen output and command syntax.

However, the implementation behind the curtain is completely different.
Interested people are invited to look into the perl source of
Netfilter_POM.pm and 'runme'.

I would like to have people start testing/using pom-ng and report errors
back to me (via email).

The differences from a user's point of view:

- dependencies are resolved recursively
- verbose error reporting
- new, more verbose './runme --man' documentation
- if you want to apply a specific set of patches, don't prefix them
  with the repository name (i.e. use
  	./runme pptp-conntrack-nat
  instead of
  	./runme extra/pptp-conntrack-nat

The differences from a developer's point of view:

- support for requirements (i.e. kernel >= 2.4.22)
- recursive dependencies
- support for multiple kernel build systems (i.e. 2.4.x and 2.6.x)
- automatic creation of Configure.help entries / Kconfig help sections
  from the patches 'help' file
- no wholefile-patches in CVS.  This means that entirely new files like
  net/ipv4/netfilter/ipt_foo.c / ipt_foo.h are not stored as patches but
  rather in their original form.   This in turn means real version
  control on the sourcecode!
- backend seperated from frontend (i.e. other user frontends could be
  implemented
- not limited to the linux sourcecode.  It is easy to add support for
  other projects (if a patchlet would have to patch other software, too)

However, some stuff is still missing (see the patch-o-matic/TODO file).
I'm working on implementing those missing features, though.

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie