Re: The role of "distro" and "image"

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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@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@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@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 know exactly how much attention people pay to the WARNING messages :(
(those are getting cleaned up so hopefully those WARNINGS that are still
present become more meaningful/serious)

Cheers,

Richard