On Mon, Mar 18, 2019 at 03:15:59PM -0700, Andre McCurdy wrote: > On Mon, Mar 18, 2019 at 1:00 PM Adrian Bunk <[email protected]> wrote: > > > > On Mon, Mar 18, 2019 at 11:35:05AM -0400, Tom Rini wrote: > > >... > > > I am however asking if the Boost project is an example > > > of something that, based on my own history building boost stuff and > > > comments from others, if something where "project says it's stable" is > > > not something that is stable enough for us. > > > > No, it would be wrong to blame the Boost project for anything here. > > > > Boost upgrades like 1.68.0 -> 1.69.0 always change the sonames of all > > libraries, and they do contain API-incompatible changes (in this case > > including removing a library). > > > > The commit comment in the thud branch even states > > "Drop signals library as upstream has removed it". > > > > If you are looking for an example for an upgrade that would be obviously > > inappropriate for a stable branch, it would be hard to imagine something > > more obvious. > > > > I am not writing this for blaming someone for past mistakes, but to make > > it clear that the actual problem with upgrades of recipes like boost or > > lighttpd in thud was that they came from the upstream master branch and > > not from upstream stable branches (which don't exist in these cases). > > We could perhaps make better use of existing tools which track API
ABI, not API, is what they track. > changes in open source packages to get a feeling for which updates to > consider for stable branches: > > https://abi-laboratory.pro/ There are easy, hard and impossible to detect ABI changes. There have been OpenSSL letter releases that changed the semantics of existing functions without changing the function signatures, which is in the "impossible to detect" category. > For example, just based on the level of API changes, upgrades to boost > should clearly be treated with some caution: > > https://abi-laboratory.pro/index.php?view=timeline&l=boost One more red flag for a boost upgrade won't make a difference. And non-library upgrades are equally problematic. Any solution that would flag that lighttpd 1.4.50 -> 1.4.51 was an upgrade from the upstream master branch would en passant also handle the boost case. All these "Can we trust upstream?" discussions miss the actual problem that the current problematic cases were not even on upstream stable branches. And the solution for this might be as simple as the stable maintainer asking whether this is an upgrade on the same stable upstream branch when the commit metadata doesn't already state that it is. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed _______________________________________________ Openembedded-architecture mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
