OpenConnect 9.01 does not work under Ubuntu 20.04

[David Woodhouse]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5965 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20220504/205c09c4/attachment.p7s>