All your explanations make sense. I'm aligned with your choice. Thanks. Le lun. 7 juil. 2025, 14:45, Jean Delvare <[email protected]> a écrit :
> Hi Erwan, > > Thanks for your feedback. > > On Fri, 4 Jul 2025 10:52:13 +0200, Erwan Velu wrote: > > That also breaks the coherency with previous versions. Does it makes > sense > > to decide an older version with the new one ? > > Are you suggesting that we should change how these types are named in > the output of dmidecode, based on which SMBIOS version the firmware > claims to implement? > > We do that for a number of fields already, most notably the system > UUID. However, the feedback we got for doing that in the past wasn't > exactly positive, as it tends to cause even more confusion that it is > trying to avoid. > > And it does not actually solve the compatibility problem, as script > maintainers still need to adjust their code at some point. With a > straightforward change in dmidecode, scripts must be adjusted to work > with both old and new versions of dmidecode. With a SMBIOS > version-based change, scripts must be adjusted to work with both old > SMBIOS implementations and new SMBIOS implementations. The code changes > needed will be pretty much the same in both cases. > > The drawback with only affecting newer SMBIOS implementations, is that > it moves the change to a point in the future when the breakage is least > expected. When a system administrator updates a package such as > dmidecode, they can expect that custom scripts could break and they will > test that. If the breakage only happens when moving to a more recent > SMBIOS implementation, then it will happen when installing the same > system to more recent hardware, or upgrading existing hardware, or even > simply updating the firmware. System administrators would not expect > changes to type or field names in the output of dmidecode to happen on > such operations. > > On virtual machines, this would also cause the dmidecode output to > differ depending on the hypervisor (the product and possibly even the > version). Again I think people will be surprised if the same version of > dmidecode uses different names for the same type depending on which > cloud provider is being used. > > As a conclusion, I see more drawbacks than benefits in going that > route, if this is what you were suggesting. > > -- > Jean Delvare > SUSE L3 Support >
