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

[Daniel Dickinson]

On Wed, 22 Mar 2017 08:33:17 -0400
Bruce Ashfield <bruce.ashfield at gmail.com> 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 gmail.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.
> 

Wouldn't that make the openstack layer more of a distro or distro
fragment then?  Wouldn't it make sense to have a openstack.bbclass and
INHERIT in local.conf or distro.conf (depending on whether create a
distro or a one-off test?) that takes care of the specific
dependencies for that specific use-case?

Specific use-cases seems to be the point of distros and images to me,
whereas recipes should be pick and choose...

Regards,

Daniel