When building OpenBMC . . . ?

[Patrick Voelker]

> On Wed, Sep 02, 2020 at 06:50:01PM +0000, Patrick Voelker wrote:
> > I'm giving the first option below a try.  I've defined an alternative variant
> and have included the meta-facebook/meta-tiogapass layer in my build.
> >
> > One problem I'm running into is that meta-tiogapass includes a
> rsyslog*.bbappend and one of the other layers I'm using also has a similar
> rsyslog*.bbappend.
> >
> > Each do an append to do_install() and each one tries to remove
> ${D}${sysconfdir}/rsyslog.d/imjournal.conf.  Of course that file can only be
> removed once so the build fails.
> >
> > My question now, is what's the best way to work around this?  I don't need
> rsyslog from meta-tiogapass, just the machine specifics.
> 
> If this is a common pattern, we should try to contribute it upstream to Yocto
> as a PACKAGECONFIG option.  Then we can add to the PACKAGECONFIG in
> the bbappend (you can do that as many times as you want).
> 
> If we don't think Yocto would accept it, or they reject it, but it is still
> something we're seeing often in our systems we can similarly add it as a
> common bbappend in meta-phosphor (ideally triggered by a
> PACKAGECONFIG).

Thanks for the response but I'm having a hard time connecting the dots.

My understanding of PACKAGECONFIG is that it's a way to provide build options for individual packages.  In this case, what PACKAGECONFIG option would we be contributing?

Is there a way now for me to force bitbake to ignore (or not use) rsyslog*.bbappend in meta-tiogapass from another layer?

The two appends that are conflicting are:
meta-facebook/meta-tiogapass/recipes-extended/rsyslog/rsyslog_%.bbappend
meta-intel/meta-common/recipes-extended/rsyslog/rsyslog_%.bbappend

Can I choose one over the other instead of having them build upon eachother?