Hi Jan, > [...] > >>> +# > >>> +# Shared libraries > >>> +# > >>> +LIBEBGENV_SO_VERSION = $(shell $(EGREP) -o '[0-9]+\.[0-9]+' VERSION) > >> > >> Do we want to couple the lib version that tightly to the releases? > > > > Well, there's the take on library versioning by autotools > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.sourceware.org%2Fautobook%2Fautobook%2Fautobook_61.html&data=04%7C01%7Cf12e6810-e622-4957-a0c8-c67ff4e321b6%40ad011.siemens.com%7C08351ec4ecb04268282c08d967b695f3%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637654856164997542%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hdRsokE7Iaz80fAejGQ96EXjbvi8Rj7srjfHbsHj67w%3D&reserved=0 > > but their semantics seems not to be too widely adopted. > > > > The downside of using the version in the shared library names, quoting > > above link: > > "[...] and you don't mind forcing your users to relink all of the > > applications which use one of your Libtool libraries every time you > > make a release, then libtool provides the '-release' flag to encode > > the project version number in the name of the library [...]" > > is usually handled by distributions that exactly do this: repackage > > all dependencies and roll out the update to users ― except for > > self-built packages that you have to take care for locally.... > > > > Another option would be to bump the version on breaking changes only, > > manually, and thus decoupling from the "real" version. > > > > Either way, one has to solve the problem of either relinking dependent > > applications on version bumps (and installing the updated EFI bootloader > > part) or allowing to have multiple versions of the shared library > > installed. In the latter case, one must ensure compatibility to the EFI > > bootloader part also touching BGENV.DAT so not to use an outdated shared > > library to access it. > > > > > > So... what are we going to do? :) > > > > The compatibility to bgenv.dat revisions is the task of the lib, in the > future, see the other thread.
Exactly. In case of multiple lib versions it doesn't help to use a lib that refuses to touch EBGENV.DAT because it's outdated, so you have to update its dependent packages to use the new lib version anyway... > But it's likely safer to avoid the manual version bump, thus forgetting > an update when changing the lib APIs. Agreed. So we keep the tight name-coupling of the shared library to EFI Boot Guard's version then. I'll send a V2... Kind regards, Christian -- Dr. Christian Storm Siemens AG, Technology, T RDA IOT SES-DE Otto-Hahn-Ring 6, 81739 München, Germany -- You received this message because you are subscribed to the Google Groups "EFI Boot Guard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/20210825161605.rnz5yzel5khkn4gp%40MD1ZFJVC.ad001.siemens.net.
