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

[Robert P. J. Day]

On Wed, 22 Mar 2017, 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 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.

  ok, i see your point ... i will ponder this. it still seems ...
unclean.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================