From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-07
Date: Tue, 11 Feb 2014 08:18:25 +0100 [thread overview]
Message-ID: <52F9CEC1.2030200@mind.be> (raw)
In-Reply-To: <20140210210752.641364a8@skate>
On 02/10/14 21:07, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
>
> On Mon, 10 Feb 2014 18:39:48 +0100, Arnout Vandecappelle wrote:
>
>>>> This one I agree is old. The question is: how do I exclude this package
>>>> from being built. Should we introduce hidden Config.in bools for kernel
>>>> header versions, so that the packages that need at least the kernel
>>>> headers from kernel X.Y are not visible if you have a too old
>>>> toolchain? Those bools would be set by linux-headers/Config.in for the
>>>> internal backend, automatically set for the well-known external
>>>> toolchains, and a custom choice for special external toolchains.
>>>
>>> I think we should indeed implement a mechanism to restrict packages
>>> based on kernel headers.
>>> There have been many packages that require recent kernel headers, and
>>> it is not feasible to fix all these packages individually. Forcing the
>>> user to update their kernel headers or toolchain is not unreasonable,
>>> and otherwise they are always welcome to propose a patch for a
>>> particular package, or discuss the matter upstream.
>>>
>>> The solution you propose seems a good idea to me and not too complex.
>>
>> I had also thought about this option already. However, I expect the "not
>> too complex" is not entirely true: you probably want symbols from
>> something like 2.6.36 up to 3.13... Hm, that's just 20 symbols, maybe not
>> so bad after all. However, for custom external toolchains and for custom
>> kernel headers, all of these have to be made visible as well, so that
>> adds another 20 symbols...
>
> True, but I don't really see another solution that solves the problem
> at hand...
Neither do I.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
next prev parent reply other threads:[~2014-02-11 7:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-08 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-02-07 Thomas Petazzoni
2014-02-08 12:49 ` Yann E. MORIN
2014-02-10 8:31 ` Thomas Petazzoni
2014-02-10 10:27 ` Thomas De Schampheleire
2014-02-10 17:39 ` Arnout Vandecappelle
2014-02-10 20:07 ` Thomas Petazzoni
2014-02-11 7:18 ` Arnout Vandecappelle [this message]
2014-02-10 17:31 ` Yann E. MORIN
2014-02-10 17:44 ` Thomas De Schampheleire
2014-02-10 17:51 ` Thomas Petazzoni
2014-02-10 17:55 ` Yann E. MORIN
2014-02-10 17:51 ` Yann E. MORIN
2014-02-10 17:44 ` Thomas Petazzoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52F9CEC1.2030200@mind.be \
--to=arnout@mind.be \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.