[oe] [PATCH 1/5] Use common files for AT91SAM9 configuration

[Frans Meulenbroeks]

2010/10/19 Philip Balister <philip at balister.org>:
> On 10/18/2010 07:10 PM, Ulf Samuelsson wrote:
>>
>> Khem Raj skrev:
>>>
>>> On Mon, Oct 18, 2010 at 10:10 AM, Ulf Samuelsson
>>> <ulf.samuelsson at atmel.com>  wrote:
>>>>
>>>> Koen Kooi skrev:
>>>>>
>>>>> On 18-10-10 15:38, Ulf Samuelsson wrote:
>>>>>>
>>>>>> Marcin Juszkiewicz skrev:
>>>>>>>
>>>>>>> Dnia sobota, 16 pazdziernika 2010 o 14:50:02 ulf.samuelsson at atmel.com
>>>>>>> napisaB(a):
>>>>>>>
>>>>>>>> +++ b/conf/machine/include/at91-2.6.30.inc
>>>>>>>> +++ b/conf/machine/include/at91-2.6.32.inc
>>>>>>>
>>>>>>> Do you plan to duplicate that file with each kernel you will produce?
>>>>>>> Create include/at91-sam9.inc and put it there.
>>>>>>>
>>>>>>> Regards,
>>>>>>
>>>>>> This is to allow different kernel versions for different AT91 chips.
>>>>>> This allows both a "stable" version, and a development kernel
>>>>>> to be easily handled.
>>>>>> The file defines (amongst other things) the
>>>>>> * kernel version,
>>>>>> * u-boot version
>>>>>> * at91bootstrap version
>>>>>> so you need one file per version.he
>>>>>
>>>>> NAK! Machines don't get to decide versions! Please revert that commit
>>>>> and come up with a better way, e.g. default_preference in the recipes
>>>>> or
>>>>> distro include files.
>>>>
>>>> If I look at the machine files, almost all of them provide
>>>> a preferred kernel / u-boot. Some also provide version.
>>>
>>> we should avoid pinning versions there. Choosing a type is fine.
>>>
>>
>> Why ?
>> Is it because it affect rebuild time?
>> It would be good to understand what problems people see with this.
>>
>> We are pinning the version to a specific machine, in the kernel recipe.
>> If we add a new recipe, then we can, by increasing the priority
>> force a different kernel to be built.
>> This will not affect anything else.
>>
>> If the version is in the machine configuration, then a change of
>> kernel version could force a total rebuild, or?
>>
>> Any other problem?
>
> In general, if you pin a version in a machine file, consider what happens in
> the case of a distro that supports many machines. Your machine build one
> version of something and the other machines build another.
>
> now do an update, upgrade on a package the version you chose may change, or
> it may change on the other machines. There are likely some packages you can
> pin version in machine files, but in general, it will cause problems for
> distros that support more than just one machine at a time.
>
> Philip
>
It does not cause a problem if it are machine specific recipes (things
like linux, u-boot etc. those which end up in tmp/work/${MACHINE}...
(and actually it seems logical to let the machine decide for those)

It may (and most likely will) cause problems in the way you describe
for the recipes that are arch specific and not machine specific.
One exception: if a pinning applies for *all* systems in the arch.
E.g. for nios2 gcc 4.1.2 is still the only option so pinning it would
cause no damage (but there it has been resolved in a different way)

Frans.