OpenConnect 9.01 does not work under Ubuntu 20.04

[Luca Boccassi]

On Wed, 2022-05-04 at 19:24 +0100, David Woodhouse wrote:
> 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? 

It makes sense to maintain a symbols file only if each version is
annotated with the exact package version that first introduced it, so
that dpkg can generate the minimal dependency required based on the
subset of symbols used by the building package, picking the version of
the most recent one. Otherwise it has no benefits, and only maintenance
costs.

> > 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.

A symbols file wouldn't help with that, as it would make things more
lax, not more strict. Forcing installations through dpkg is always
possible - it is a user error in most cases. The OBS page clearly lists
the repository and the instructions to use it first via apt, bypassing
that should not be done unless one knows exactly what they are doing.

-- 
Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20220504/d6dac011/attachment.sig>