Re: Linux 2.6.32-rc3

Frans Pop
2009-10-07T05:57:22Z

On Wednesday 07 October 2009, Bryan Donlan wrote:
> On Tue, Oct 6, 2009 at 12:36 PM, Frans Pop <elendil@planet.nl> wrote:
> > BTW, I've got a solution for bisection too: the versions in the
> > Makefile get changed to something constant. And the package version is
> > set equal to the bisection iteration. This ensures that I know exactly
> > which kernels were build for the series and that I can always go back
> > to a specific kernel if I need to retest for some reason.
> >
> > E.g. (for a bisection covering .30-.31):
> > linux-image-2.6.31-bisect_1_amd64.deb
> > linux-image-2.6.31-bisect_2_amd64.deb
> > linux-image-2.6.31-bisect_3_amd64.deb
>
> It should be noted that implementing this would result in the package
> names becoming wildly inconsistent if you bisect over the point where
> this feature is introduced.

It is already supported :-)
But yes, what you note is an issue, though one that automatically fades
with time. And it is softened by the fact that the scheme is not default.
The default package versioning was unchanged when the option was added.

> In order to be useful, it would need to
> determine if its own implementation commit is shadowed by the 'bisect
> good' marker, make a note of this in a non-overwritten location (.git,
> eg), then disable itself and use the old behavior if it would bisect
> over its own introduction.

I deal with it in my wrapper script: that tests if the implementation
commit is present and, if not [1], replaces scripts/package/builddeb with
a version that does support it. That works for quite a long time back.
The wrapper script also reverts the change after each build so the
following good/bad does not fail because the tree is dirty.

Cheers,
FJP

[1] It was introduced with .30: v2.6.30-rc8-79-gc72c75d.