<div dir="ltr">There is also the opposite use case where people are using bitbake to build intentionally older release of OE metadata and bitbake often isn't backwards compatible. So as Paul said they need to use older release of bitbake with older release of metadata and the latest version of bitbake from their favorite distribution won't be compatible with it.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 9, 2017 at 4:53 AM, Neal Gompa <span dir="ltr"><<a href="mailto:ngompa13@gmail.com" target="_blank">ngompa13@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, Nov 8, 2017 at 10:48 PM, Paul Eggleton<br>
<<a href="mailto:paul.eggleton@linux.intel.com">paul.eggleton@linux.intel.com</a><wbr>> wrote:<br>
> Hi Neal,<br>
><br>
> On Thursday, 9 November 2017 12:58:08 AM NZDT Neal Gompa wrote:<br>
>> I'm looking reintroduce BitBake into Fedora, but it seems like there<br>
>> hasn't been releases in two years. I also cannot identify anywhere<br>
>> that provides tarballs of BitBake to package.<br>
>><br>
>> The Fedora package previously referenced snapshot tarballs generated<br>
>> by tagged releases in OE Git, but there haven't been new tagged<br>
>> releases in two years.<br>
>><br>
>> I'd previously asked this on oe-core ML and was redirected to<br>
>> bitbake-devel, so apologies to cross-list subs. But it was also<br>
>> pointed out there that apparently BitBake has moved to a model where<br>
>> they don't have stable points of releases, which seems rather odd for<br>
>> a tool that is used by more than OpenEmbedded.<br>
><br>
> It's not that we don't have stable points - we do, it's that from the other<br>
> side, each stable release of OE-Core is only tested with the corresponding<br>
> stable release of BitBake, so if people start using BitBake from their distro<br>
> we are probably going to have extra mismatch issues to deal with. We really<br>
> ought to be tagging releases, not having done that is an oversight but it's<br>
> reflective of the current typical usage.<br>
><br>
> It would be nice to get some exposure of BitBake as a standalone tool, and<br>
> having it packaged by distros might be one way to help that, but my concern<br>
> for OE usage would be that when this has been done in the past we have had<br>
> situations where BitBake from the distro has been older than needed by OE-Core<br>
> and users end up having to fetch it themselves anyway, so we'd have to have a<br>
> strategy for handling that.<br>
><br>
> (This is not necessarily an official answer - I'd be interested to hear what<br>
> RP and others have to say about it.)<br>
><br>
<br>
</div></div>For what it's worth, if you guys are regularly tagging BitBake, this<br>
can be automatically tracked in Fedora infrastructure and I can update<br>
BitBake relatively quickly after that.<br>
<br>
Unlike most distributions, it's usually not a problem to update<br>
relatively frequently in Fedora. But that doesn't mean you should<br>
stress me out with tons of releases out the wazoo. :)<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
--<br>
真実はいつも一つ！/ Always, there's only one truth!<br>
</font></span><div class="HOEnZb"><div class="h5">--<br>
______________________________<wbr>_________________<br>
bitbake-devel mailing list<br>
<a href="mailto:bitbake-devel@lists.openembedded.org">bitbake-devel@lists.<wbr>openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/bitbake-devel" rel="noreferrer" target="_blank">http://lists.openembedded.org/<wbr>mailman/listinfo/bitbake-devel</a><br>
</div></div></blockquote></div><br></div>