| Summary: | bind is even = stable, need to upgrade to 9.16.x | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Tim Orling <tim.orling> |
| Component: | core | Assignee: | akuster <akuster808> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | High | CC: | akuster, bunk, meta.mr.watcher, meta.watcher, randy.macleod, richard.purdie |
| Version: | 3.1 | ||
| Target Milestone: | 3.1 M3 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Don't know | |
|
Description
Tim Orling
2020-02-15 05:08:40 UTC
They do stable once a year and extended support on certain versions like 9.11. BIND 9.11 is an Extended Support version, and will be supported until December, 2021. So does OE want latest or long term versions? 9.14 will be EOL by the end of this year. Please see: https://kb.isc.org/docs/aa-00896 The recipe already follows the ESV versions: # stay at 9.11 until 9.16, from 9.16 follow the ESV versions divisible by 4 UPSTREAM_CHECK_REGEX = "(?P<pver>9.(11|16|20|24|28)(\.\d+)+(-P\d+)*)/" I would recommend against switching to short-term stable releases like 9.14. Thank you both for the clarity. I agree with the extended support sentiment, so we should wait until 9.16. one thing not talked about if we should have the latest stable bind recipe that folks could enable via PREFERRED-VERSION. I have been thinking about have one just to keep up the build breakages as things move along in the bind world. It might make transitions easier between EOS versions. (In reply to comment #4) > one thing not talked about if we should have the latest stable bind recipe > that folks could enable via PREFERRED-VERSION. > > I have been thinking about have one just to keep up the build breakages as > things move along in the bind world. The common build breakage are new bind versions breaking the build of the dhcp recipe. Which usually needs fixing of dhcp. > It might make transitions easier between EOS versions. Who will do the additional work of maintaining the non-default version? The overall amount of work increases when maintaining two versions, and problems seen with 9.14 might already have been fixed by upstream for 9.16. Could be a case for enabling and testing in poky-bleeding? :) Although I would love to live in the world where we could do the poky-bleeding, I think reality is we continue with status quo. Meaning we stay with 9.11 until 9.16 is out. Closing. Bind 9.16.0 just dropped. Do we want to get this in 3.1 ? it needs libuv package which is in meta-oe needs to check 3 OE specific patches. Here is what I have so far. https://git.openembedded.org/openembedded-core-contrib/log/?h=akuster/bind_9.16_wip Armin agreed to do this. patches sent https://patchwork.openembedded.org/patch/170608/ https://patchwork.openembedded.org/patch/170609/ This bind update requires a newer dhcp to be released which one has not. This therefore will not make 3.1 |