Subject: Re: [vserver] Request - please avoid patching EXTRAVERSION?
From: Ed W <lists@wildgooses.com>
Date: Fri, 11 Feb 2011 17:43:44 +0000

Hi

>> These merge conflicts would disappear if you would be kind enough to
>> switch to using the "localversion-" method to add EXTRAVERSION params
>> rather than patching the Makefile?
> assuming that you use the proper base kernel, I don't
> see why that chunk would cause any merge failures ...

That's basically the point, I kind of don't want to use the correct base 
kernel...

OK, stop there before you panic... The point is not to give you support 
grief, but that patch management tools such as git don't think in terms 
of "patches against specific versions", but they tear up the code into a 
series of change sets which are stacked on top of each other:

I'm trying to use git to keep a fixed series of vserver patches and 
forward port the *kernel* on those patches (kind of the opposite of how 
you would develop the patchset).  So I'm having some success in:

- branch mainline kernel on say 2.6.36
- patch vs-2.6.36(.0)
- merge kernel changes up to 2.6.36.1
- patch vs-2.6.36.1 onto vanilla and commit that (basically giving the 
incremental vs patch)
- merge kernel changes up to 2.6.36.2
- patch vs-2.6.36.2 , etc, etc

The important bit is that this gives the incremental changes at each 
step to move upwards in time (obviously beware that only certain points 
are tested working kernels, but that's not the purpose or a 
limitation).  However, this appears to make it quite straightforward to 
merge several such trees of patchsets together

In my case I'm looking at maintaining a grsec or pax + vserver + aufs 
patchset.  It's fairly straightforward to use the procedure above to 
work out the incremental patchset for each kernel version and 
maintaining the joint patchset is vastly easier because we can largely 
maintain only the incremental changes at each stage.  So far in my 
experiments merging through non major kernel re-org work has been quite 
straightforward and maintaining a hybrid patch is much simpler

However, in the case of linux-vserver, once I apply the vs patch, then 
try and pull all the new kernel commits to get me up to the next kernel 
version (in prep to apply the next vs patch), I always get a merge 
failure on the EXTRAVERSION bump commit... So far I don't know how to 
script an automated fix to a git merge and then restart the merge... 
It's basically quite a slowdown in the otherwise simple process of 
maintaining the patch...


> we use the EXTRAVERSION to ensure that everybody who
> uses the patch on a different kernel release as intended
> gets a proper 'warning' at patch time,

It would appear that it doesn't quite achieve this?  Only checks that 
you use the correct minor kernel version? Not that the major version is 
correct?

Also, is this useful?  Your biggest problem on the list seems to be 
debian users still on 2.6.9 or something antique, not users trying to 
apply the patch to some release candidate of the next kernel?

Also, not that I am advocating users trying this, but from my very 
limited observation so far, largely the patch for 2.6.x.1 seems 
appropriate to apply to 2.6.x.2?

> I don't see why that would be hard to automate for you,
> after all, I automated the EXTRAVERSION change as well,
> with a simple sed line ...

I am trying to use a more modern patch management process, in this case 
git.  It has automated processes to maintain a series of patches and 
there isn't an obvious way to insert an extra step to run some sed 
recipe part way through a merge?  I dont think the situation would 
change if I used mercurial/bzr/quilt, etc though - fundamentally it's a 
deliberately inserted merge failure (in your case to stop the 
theoretical mis-application to the wrong version, in my case stopping me 
easily generating a series of incremental patches)


Additionally every patchset wants to show it's hand in EXTRAVERSION, and 
localversion- was basically added to make this process scalable (I want 
to show aufs+grsec as well as vs versions)

I would be grateful if you would weigh up a genuine (small) barrier to 
using the vserver patch more easily/widely vs the possibility of someone 
learning to use the "-p1" feature of patch and then "accidently" 
applying the patchset to the wrong base kernel, and come down on the 
side of ease of use...  (pretty please...)



I will write a second email with a suggestion on how you might find git 
useful for your own internal process - so far it seems like it might 
work pretty well for forward porting vserver patches to new kernels?!  
(To be clear, I'm doing the reverse, forward porting the kernel onto the 
old patch...)

Kind regards

Ed W