[yocto] The role of "distro" and "image"

[Chris Larson]

On Thu, Dec 15, 2011 at 2:18 PM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Thu, 2011-12-15 at 10:54 -0700, Chris Larson wrote:
>> On Thu, Dec 15, 2011 at 10:29 AM, Koen Kooi <koen at beagleboard.org> wrote:
>> > Op 13 dec. 2011, om 22:45 heeft Chris Larson het volgende geschreven:
>> >
>> >> On Tue, Dec 13, 2011 at 2:36 PM, Richard Purdie
>> >> <richard.purdie at linuxfoundation.org> wrote:
>> >>> Not all images can be built with a given distro, our base config is
>> >>> rather ride ranging though for obvious reasons. You could "enforce" this
>> >>> by adding some anonymous python to the distro which does something like:
>> >>>
>> >>> if inherits("image") and PN != core-image-minimal:
>> >>>    raise SkipPackage("Image PN not compatible with DISTRO=XXX")
>> >>
>> >> This is a case where one is best 'controlling' this via policy, not
>> >> mechanism, in my opinion. This sort of arbitrary technical limitation
>> >> tends to be foolish and often bites someone somewhere down the line.
>> >> I'm sure you just wanted to note how it could be done, not recommend
>> >> that it should be done, but I thought it should be made clear. I
>> >> wouldn't recommend that anyone do this unless there is an extremely
>> >> good reason for it.
>> >
>> > We had a similar problem at work, people were sprinkling
>> COMPATIBLE_MACHINE left and right just to mark "I tested recipe X on
>> machine Y". You can guess what happened when new machines needed to
>> get added.
>>
>> Haha, ouch. It's also worth taking a moment to emphasize that the way
>> distro/machine/image is structured is by design, not accidental.
>> Having these pieces be orthogonal buys us a great deal of flexibility
>> and capability, which is why we did it this way. Now, whether a given
>> distro/machine/image combination is *useful* is a different question,
>> and one I think is best addressed via policy / documentation.
>
> I understand the flexibility but I also think we need to consider
> usability a little. We have people using the system to whom it might not
> be immediately obvious why building a sato image with the tiny distro is
> a bad idea.
>
> If you know enough to be able to make that work, the warning is easily
> bypassed and isn't going to bother you.
>
> So I think there is a case for warning the user if the combination
> they're selecting is not one that is likely to work and we can easily
> predict it. There are many combinations we can't predict which is fine.


There's a rather large difference between *warning* the user and
raising SkipPackage, making it not possible to build without modifying
the recipe.
-- 
Christopher Larson