On Wed, 2022-05-04 at 19:19 +0100, Luca Boccassi wrote: > On Wed, 2022-05-04 at 19:12 +0100, David Woodhouse wrote: > > On Wed, 2022-05-04 at 18:59 +0100, Luca Boccassi wrote: > > > The same can be done by maintaining a symbols file. I do that for the > > > actual Debian/Ubuntu builds ( > > > https://salsa.debian.org/debian/openconnect/-/blob/master/debian/libopenconnect5.symbols > > > > > > ), but it's a _lot_ of work and it would constantly break the builds > > > as new things are added/removed, so I did not add it to the upstream > > > builds. > > > > It shouldn't break the build as things are added; surely that's the > > point? > > I'm quite sure it's flagged as an error by Lintian if there's a symbol > missing in the list. > > > It *should* break the build if things are removed without bumping the > > soname. Which is also the point :) > > > > But I don't really understand why Debian lists each individual symbol. > > The library *minor* version really ought to be enough for any even > > semi-sanely-maintained library. And if the library is *so* badly > > maintained that it isn't enough, all bets are off anyway; the developer > > might even break binary ABI between versions *without* changing symbol > > names or version, surely? > > I'm not sure why the tooling works the way it does, maybe historical > reasons, it's ancient stuff. > > > Anyway, for OpenConnect this script ought to be able to build the > > symbols file from openconnect.h, which does have a history of when each > > symbol was added: > > http://git.infradead.org/users/dwmw2/openconnect-deb.git/blob/HEAD:/gensyms.sh > > > > It would have to be ran manually every time.
I thought it could be automated as part of debian/rules? > I'm not sure it's worth > the hassle, for this setup? Is there any issue with lock-step updates? The only issue with the lock-step updates is that Dominik managed *not* to update them in lock-step, it seems :) For the Fedora packages we just ship the library and binary together in the *same* package, and that means they are very much in lock-step anyway. The binary uses private exports from the library that are very much *not* API-managed. The normal library API hygiene doesn't help at all there.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
