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

[Chris Larson]

On Thu, Dec 15, 2011 at 4:06 PM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Thu, 2011-12-15 at 15:56 -0700, Chris Larson wrote:
>> 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.
>
> What's needed is something which results in a "stop the build and force
> the user to change something to continue" so I'm not sure I see the
> problem with that.

I strongly disagree. That's exactly what we shouldn't have, at least
unless there's an easy way to disable the behavior. Even our sanity
checks can be opted out, and those are far more critical than building
a rootfs that might not behave in a useful fashion on a particular
piece of hardware.
-- 
Christopher Larson