[OE-core] design question: should layer.conf contain "PREFERRED_VERSION" settings?

[Richard Purdie]

On Wed, 2017-03-22 at 08:33 -0400, Bruce Ashfield wrote:
> 
> 
> On Wed, Mar 22, 2017 at 8:24 AM, Robert P. J. Day <rpjday at crashcourse
> .ca> wrote:
> > 
> >   proper attributions seem to have been totally lost here ...
> > 
> > On Wed, 22 Mar 2017, Bruce Ashfield wrote:
> > 
> > > On Wed, Mar 22, 2017 at 8:02 AM, Burton, Ross <ross.burton at intel.
> > com> wrote:
> > >
> > >       On 22 March 2017 at 11:57, Bruce Ashfield <bruce.ashfield at g
> > mail.com> wrote:
> > >             So where are they supposed to be specified ? Surely
> > not a separate distro .conf ? and most
> > > certainly not in local.conf ... I've always been unsure of where
> > the right place to specify 
> > > versions like that.
> > >
> > > If it were my layer I'd have an .inc file that set all the
> > preferred
> > > versions where the defaults don't work, that the user would have
> > to
> > > include in their distro.
> > >
> > > Aha. Kind of like the old versions file that used to float
> > around.
> > >
> > > Seems reasonable (if a bit less automatic than someone like me
> > who
> > > wants .. to use the layer like a black box)
> > >
> > > Luckily I have push access to that layer, so I can make a change
> > > like that ;)
> > >
> > > One final question, is it considered a design option to set those
> > > versions triggered off an IMAGE or DISTRO feature ? i.e. in
> > > anonymous python .. or is that already too late in the
> > > parsing/resolution process ?
> > >
> > > Bruce
> > 
> >   sorry, didn't mean to start something this early in the morning
> > ...
> > ok, i did. :-)
> > 
> >   in any event, can we agree that:
> > 
> > 1) it's bad layer design if the simple act of including a layer in
> > bblayers.conf suddenly causes weird things to happen like the
> > above?
> > 
> > 2) regardless of how the developer eventually does it, picking up
> > those PREFERRED VERSIONS from meta-openstack should require *some*
> > kind of explicit selection?
> 
> Honestly .. I disagree on #2.
> 
> The packages within the openstack layer *will not work* with other
> versions of those
> packages. 
> 
> So if someone actually wants to use the functionality provided by the
> layer, they are
> not optional. And the errors/issues that you get are extremely obtuse
> and hard to
> debug. That's the design point of the layer .. it doesn't let that
> happen.
> 
> Hence making it something they must do as an extra step .. really is
> a bad idea.
> 
> It gets in the way of people picking packages out of that layer if
> they don't want to 
> actually build openstack, that's the crux of the problem. But to
> answer that issue,
> that's why meta-cloud-services exists, that doesn't' force versions
> and holds the
> generally useful "cloud" packages.

Having layers which magically change the "policy" such as selected
versions goes against the spirit and wording of Yocto Project
Compatible (and will go against the new layer checking tools).

What should happen is that the openstack recipe should complain loudly
(error) if anyone tried to build it (or parse it?) with anything except
the versions its known to work with.

Cheers,

Richard