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
Received on Fri Feb 11 17:46:49 2011