| Message ID | 20250624104155.559827-1-yi.zhao@windriver.com |
|---|---|
| Headers | show |
| Series | fix runtime versions | expand |
On Tue, 24 Jun 2025 at 12:42, Yi Zhao via lists.openembedded.org <yi.zhao=eng.windriver.com@lists.openembedded.org> wrote: > This series of patches was sent in April. Ross suggested discussing this > with upstream to see if they could update the scripts to address the > issue. I talked to upstream and they declined because they believed that > "autoreconf may result in different built source code than what has been > distributed"[1]. Is there a benefit of carrying these patches in core to the broader community? I don't think anyone's particularly confused or misled by 'unknown' reported by executables at runtime, we have procedures to verify that what we build is exactly what upstream has released, and various built time reporting mechanisms to see the versions. Wind River obviously has invested a lot of time and effort into this, presumably because it has a paying customer that is obsessed about what executables on target say, but I do struggle to justify carrying and maintaining these fixes. Alex
On Tue, 2025-06-24 at 12:50 +0200, Alexander Kanavin via lists.openembedded.org wrote: > On Tue, 24 Jun 2025 at 12:42, Yi Zhao via lists.openembedded.org > <yi.zhao=eng.windriver.com@lists.openembedded.org> wrote: > > This series of patches was sent in April. Ross suggested discussing this > > with upstream to see if they could update the scripts to address the > > issue. I talked to upstream and they declined because they believed that > > "autoreconf may result in different built source code than what has been > > distributed"[1]. > > Is there a benefit of carrying these patches in core to the broader > community? I don't think anyone's particularly confused or misled by > 'unknown' reported by executables at runtime, we have procedures to > verify that what we build is exactly what upstream has released, and > various built time reporting mechanisms to see the versions. > > Wind River obviously has invested a lot of time and effort into this, > presumably because it has a paying customer that is obsessed about > what executables on target say, but I do struggle to justify carrying > and maintaining these fixes. I guess it raises the question of patch vs sed too. Would this be more maintainable if we just had a common sed like function to take these out of autogen.sh? If it breaks, it isn't the end of the world... There is the advantage that it is relatively standardised. Cheers, Richard
On 6/24/25 18:50, Alexander Kanavin wrote: > On Tue, 24 Jun 2025 at 12:42, Yi Zhao via lists.openembedded.org > <yi.zhao=eng.windriver.com@lists.openembedded.org> wrote: >> This series of patches was sent in April. Ross suggested discussing this >> with upstream to see if they could update the scripts to address the >> issue. I talked to upstream and they declined because they believed that >> "autoreconf may result in different built source code than what has been >> distributed"[1]. > Is there a benefit of carrying these patches in core to the broader > community? I don't think anyone's particularly confused or misled by > 'unknown' reported by executables at runtime, we have procedures to > verify that what we build is exactly what upstream has released, and > various built time reporting mechanisms to see the versions. > > Wind River obviously has invested a lot of time and effort into this, > presumably because it has a paying customer that is obsessed about > what executables on target say, but I do struggle to justify carrying > and maintaining these fixes. This is exposed by version check using check-version-mismatch.bbclass. In some cases, a mismatch between the runtime version and the build-time version can cause confusion for users. On the other hand, this suffix does not exist in other distributions. I will follow Richard's suggestion. Use a more standardized approach. Thanks, Yi > > Alex