> > > 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.
Yeah, understood. That script *does* build a symbols file with the correct "first version" for each symbol, because that information is there in text form in the changelog at the top of openconnect.h It basically builds a file which is the same as the one you're doing by hand, although you ought to be marking the @OPENCONNECT_PRIVATE symbols as *new* in each release because they have no ABI guarantee; they shouldn't be considered the same as the same named symbol in 6.0 as your symbols file suggests. > > 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. Especially if you mark those symbols as being compatible with v6.0 :) > 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. Agreed.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel