On Thu, 2011-12-15 at 15:56 -0700, Chris Larson wrote: > On Thu, Dec 15, 2011 at 2:18 PM, Richard Purdie > <[email protected]> wrote: > > On Thu, 2011-12-15 at 10:54 -0700, Chris Larson wrote: > >> On Thu, Dec 15, 2011 at 10:29 AM, Koen Kooi <[email protected]> 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 > >> >> <[email protected]> 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 _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
