"Adam D. Barratt" <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
