[Buildroot] [PATCH v2] linux: make custom versions and patches exclusive

[Danomi Manchego]

Yann,

On Wed, Jan 7, 2015 at 1:35 PM, Yann E. MORIN <yann.morin.1998 at free.fr> wrote:
> Danomi, All,
>
> On 2015-01-06 20:43 -0500, Danomi Manchego spake thusly:
>> On Tue, Jan 6, 2015 at 5:25 PM, Vivien Didelot
>> <vivien.didelot at savoirfairelinux.com> wrote:
>> > When using a custom kernel (custom tarball, repository or local tree),
>> > we're using the OVERRIDE_SRCDIR internally, which means we do not apply
>> > patches. Since this is the expected behavior, show the
>> > LINUX_KERNEL_PATCH option only when using a vanilla kernel.
>>
>> Forgive me if I'm missing something obvious, but - when I look at
>> linux.mk, I see the LINUX_SITE_METHOD set to "local" only when
>> BR2_LINUX_KERNEL_CUSTOM_LOCAL is set.  Aren't the custom git and
>> custom hg selections setting the method to "git" and "hg"
>> respectively?  Patches can't be applied to the results of a tarball
>> gotten from somewhere other than kernel.org?
>
> Well, using a patch to a custom kernel does not really make sense.
>
> I'll try to summraise the discussion we had with Vivien on IRC
> yesterday, which ended up with this patch (sorry, it is a bit long..)
>
> See, using a local tree or a custom git or mercurial tree, is really a
> case of telling Buildroot: "look, I have my custom kernel, which has my
> very customisation with what I need".

I certainly understand that to be the case for the local tree (which,
again, I _think_ is the only one engaging the _OVERRIDE_SRCDIR
mechanism).  But you don't think that there would be valid cases of
acquiring a kernel via git that is not customized to the project?  For
example, at work, we use a TI part, which keeps its 2.6.37+ kernel at
arago-project.org.  So I get it by setting
BR2_LINUX_KERNEL_CUSTOM_REPO_URL to
"git://arago-project.org/git/projects/linux-omap3.git", and then apply
my project's patches to it.  Sure - I guess it _a_ custom kernel in
that its modified by TI, but it does not have all the mods _I_ need
for my specific project.  Not a valid use case?

Danomi -


> The key word here is "custom": you went to great length for having such
> a kernel in the first place, so further customising with another patch
> is not really meaningfull; you could just as well add that patch to your
> custom linux kernel to start with.
>
> So, that's the reasoning behind this patch: cutom tree? Apply any
> supplemental patch to that custom tree, and be done with it.
>
> Now, the issue Vivien encountered is that pointing Buildroot to a local
> linux tree *and* an additional patch was not working: the patch was not
> applied.
>
> The technical reason is that, when using a local linux tree, we
> internally use the same mechanism as is used for _OVERRIDE_SRCDIR.
> _OVERRIDE_SRCDIR is meant for people hacking on their package (linux or
> any other) and hijack Buildroot to use that instead of downloading the
> package from upstream. This is to be used during the development of said
> package, to avoid having to manually patch the package in output/build/
> and loose all on a 'make clean'; that way, the sources you're working on
> are outdside Buildroot.
>
> Now, because this is to be used during development, we consider the user
> has all the code he actually wants to be used in that _OVERRIDE_SRCDIR
> tree, patches already applied if needed. Furthermore, when the user is
> working on a modified version of the package, there is zero guarantee
> our bundled patches would still apply; chances are even that they will
> no longer.
>
> Then the local linux tree is just a shortcut in the menuconfig for
> telling Buildroot to look for an _OVERRIDE_SRCDIR, instead of having to
> provide a local.mk that defines that very _OVERRIDE_SRCDIR. It is just a
> courtesy to the user (and IMHO we should just completely get rid of it,
> as we can not guarantee reproducible builds from such a .config file).
>
> For all these reasons, using a cutom kernel tree (local or git or Hg) is
> just not compatible with applying patches.
>
> Hence Vivien's patch, and me hacking it.
>
> Regards,
> Yann E. MORIN.
>
> --
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> '------------------------------^-------^------------------^--------------------'