On Wed, 22 Mar 2017 08:33:17 -0400 Bruce Ashfield <bruce.ashfi...@gmail.com> wrote:
> On Wed, Mar 22, 2017 at 8:24 AM, Robert P. J. Day > <rpj...@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.bur...@intel.com> > > wrote: > > > > > > On 22 March 2017 at 11:57, Bruce Ashfield < > > bruce.ashfi...@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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
