Re: Call for testing: patch-o-matic-ng

[Harald Welte <laforge@netfilter.org>]

[-- Attachment #1: Type: text/plain, Size: 2105 bytes --]

On Wed, Dec 31, 2003 at 09:51:51AM +0100, Jozsef Kadlecsik wrote:
> Unfortunately that's not so uncommon: nf-log, raw, TRACE, TCP window
> tracking patches, conntrack refcounting/locking/etc. patches, all
> conntrack/nat helpers, all targets which modify the packet.

yes, thanks for pointing this out.

> But seriously, when patch-o-matic is used in another project, that would
> be based on some software source code which would have got a version
> number. So 'kernel version' could be replaced by 'software version' above.
> And it could be implemented in Netfilter_POM.pm, without touching 'runme'
> (I think/hope).
> 
> I believe we should avoid the structure of separated directory trees for
> the different versions of the same patch.

ok, I'll implement multiple-version support, most likely tomorrow.  Have
to think about the ideal naming convention, though.

the 'patch' file should be called 'linux.patch' anyway.  help and info
should remain the same, since the description and information is valid
for for the whole patchlet, independent of how many per-project
directories or patches exist.

a 2.6 specific patch would then be inside a linux-2.6 directory.  The
only remaining question is:

- how to encode the information 'which patch for which version' in the 
  info file ?  We would need something like
  "if linux >= 2.6.0 && linux < 2.7.0, then use linux-2.6 and
  linux-2.6.patch"

- what about patchlets that have the same wholefiles but a different
  'patch' file.  I.e. a new conntrack helper that has the same source
  file, valid for 2.4 and 2.6 - but a different diff for patching
  something into conntrack_core ?

> Best regards,
> Jozsef

Happy new year, too.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]