Re: Tags for symbols file checks
"Adam D. Barratt" <adam@adam-barratt.org.uk> writes:
> The tags can be divided in to three sets. The first is based on existing
> shlibs tests, so I've chosen the same severities as those (although
> Policy doesn't mention symbols files directly, they are generated by a
> call to dpkg-shlibdeps, which Policy does describe):
> E: pkg-has-symbols-control-file-but-no-actual-shared-libs
Minor nit: dropping "-actual" will make the tag shorter and I don't think
it changes the meaning.
> E: shlib-missing-in-symbols-control-file
This is the only one that I'd lower to a warning to start, and it's
possible that we may want to lower it further. Not all libraries are
well-suited for symbols control files; in particular, they don't work very
well for C++ libraries. So it's reasonable for a package with, say, a C
and a C++ library to only have a symbols file for the C library.
> The second set relate to errors in the structure of the symbols file
> itself. My inclination is that these should be errors as they can be
> reliably detected and for at least some of them dpkg-gensymbols will
> produce a fatal error during package build if a real symbols file
> commits the error:
>
> invalid-template-id-in-symbols-file
> syntax-error-in-symbols-file
> unknown-meta-field-in-symbols-file
Agreed.
> The final tags indicate a mismatch between the shlibs and symbols
> control files. I'm tempted to say these should be errors as they're
> clearly wrong.
>
> symbols-declared-but-not-shlib
> shlib-declared-but-not-symbols
shlib-declared-but-not-symbols may be fine by the same rationale as
mentioned above. symbols-declared-but-not-shlib is clearly an error.
Isn't shlib-declared-but-not-symbols always going to be redundant with
shlib-missing-in-symbols-control-file?
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: