I think I've come across a better solution than defining a XEN_VERSION variable that needs maintained. I think this solution is a finer, more elegant way to accommodate the dependency on a specific Xen version. First, the xen-vtpm recipe would be defined using Xen version numbers as we do with the Xen recipe. Instead of the initial recipe for xen-vtpm being xen-vtpm_1.0.bb, this would now be xen-vtpm_X.X.X.bb (where X.X.X is the version of Xen we intend to build stubdoms and vTPMs against. Second, rather than defining Mini-OS in the SRC_URI in stubdom.inc, I would create a mini-os_X.X.X.bb recipe that would create a source pacakge and stubdom.inc (or the appropriate recipe) would then include mini-os as a dependency. Slight manipulation of source dir ($S) would be necessary in the xen-vtpm recipe, but nothing we can't handle. Again, X.X.X would reflect the version of Xen we intend to build against. This would be the version number maintenance outside of the recipe and allow for easier maintenance. Let me know what you think of this idea and I can implement it in the next patchset that I will submit. Kurt On Tue, Mar 20, 2018 at 2:25 PM, Christopher Clark < christopher.w.clark@gmail.com> wrote: > > > On Thu, Mar 8, 2018 at 6:23 PM, Christopher Clark < > christopher.w.clark@gmail.com> wrote: > >> >> On Mon, Mar 5, 2018 at 7:35 AM, Kurt Bodiker < >> kurt.bodiker@braintrust-us.com> wrote: >> >>> From: kebodiker >>> >>> This commit introduces the stubdom.inc file that is required for each >>> recipe that is/will be built for Xen stubdomains. >>> >> >> >> >>> +# Couldn't find any other way to access the version of Xen used as a >>> dependency. >>> +# This version number needs changed to match version of Xen recipe >>> used in builds. >>> +XEN_VERSION = "4.9.0" >>> >> >> >> :( I understand the challenge here and sadly I don't have a better >> recommendation, but: would putting a scope on the DEPEND enable the build >> to fail fast in case >> of a mismatch? ie: >> >> DEPENDS = "xen (= ${XEN_VERSION}-r0)" >> >> > In testing, this constraint of package version doesn't produce the build > behaviour I was hoping for: bitbake doesn't enforce the version constraint > at build time and from earlier related posts on the mailing list, this > behaviour is known, so presumably is intentional. > > So: I'll retract the review comment above - ie. there's no need to touch > DEPENDS - and the XEN_VERSION variable definition going into the stubdom > recipe seems practical and reasonable. > > Christopher > > > -- Kurt Bodiker BrainTrust Holdings www.braintrust-us.com 443-296-2186 office 410-750-2119 fax -- *This email and all attachments are considered confidential and the proprietary information of BrainTrust Holdings. Unauthorized disclosure is prohibited. *