On Fri, Feb 11, 2011 at 05:43:44PM +0000, Ed W wrote: > 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: so simply do not check in that specific change, it should almost always end up in a separate patch hunk which can be removed with filterdiff or grepdiff ... if you feel like localversion, you could also grep/sed that out of the removed change and add it back there fully automated ... > 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? as the patch will also fail when the first context line (the SUBLEVEL) is different, I'm pretty sure it covers all 'real world' cases ... > 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? well, maybe that is _because_ we do it this way :) > 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? yes, but there is a difference between a patch which applies perfectly fine and a patch intended for this specific version (the former might fail at compile or runtime) > >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) as I said, perfectly fine for your personal version > 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 did, and your arguments do not convince me, sorry ... > 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...) feel free to do so, but know that I tried git several times (for Linux-VServer development) and it failed for me each time, so I went back to the (very similar) way of maintaining kernel trees in a hard linked setup which works perfectly fine ... note that I cannot help to notice that most of the arguments you brought up so far are based on the assumption that _I_ should change something in the way _we_ develop Linux-VServer to simplify _your_ work ... shouldn't it be the other way round? please don't get this the wrong way, I have been developing Linux-VServer for almost 10 years now and the procedures work reasonably well and stable, so I do not see any reason to change that in the near future without _really_good_ reasons ... best, Herbert > Kind regards > Ed W