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 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