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