documentation/poky-ref-manual/ref-classes.xml: insane.bbclass updated
Added explanation about this class being configurable for generating warnings or errors through use of the WARN_QA and ERROR_QA variables. Also provided a list of tests that can be tested for. Fixes [YOCTO #1773] Reported-by: Mark Hatle <mark.hatle@windriver.com> (From yocto-docs rev: 2b15aa9076ec120d078bfcd570001a49e81df038) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark
Richard Purdie
parent
adcf8bf7b5
commit
b16bc3d277
|
|
@ -391,6 +391,87 @@
|
|||
for common problems that show up during runtime.
|
||||
Distribution policy usually dictates whether to include this class as the Yocto Project does.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can configure the sanity checks so that specific test failures either raise a warning or
|
||||
an error message.
|
||||
Typically, failures for new tests generate a warning.
|
||||
Subsequent failures for the same test would then generate an error message
|
||||
once the metadata is in a known and good condition.
|
||||
You use the <filename>WARN_QA</filename> variable to specify tests for which you
|
||||
want to generate a warning message on failure.
|
||||
You use the <filename>ERROR_QA</filename> variable to specify tests for which you
|
||||
want to generate an error message on failure.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The following list shows the tests you can list with the <filename>WARN_QA</filename>
|
||||
and <filename>ERROR_QA</filename> variables:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis><filename>ldflags:</filename></emphasis>
|
||||
Ensures that the binaries were linked with the
|
||||
<filename>LDFLAGS</filename> options provided by the build system.
|
||||
If this test fails, check that the <filename>LDFLAGS</filename> variable
|
||||
is being passed to the linker command.</para></listitem>
|
||||
<listitem><para><emphasis><filename>useless-rpaths:</filename></emphasis>
|
||||
Checks for dynamic library load paths (rpaths) in the binaries that
|
||||
by default on a standard system are searched by the linker (e.g.
|
||||
<filename>/lib</filename> and <filename>/usr/lib</filename>).
|
||||
While these paths will not cause any breakage, they do waste space and
|
||||
are unnecessary.</para></listitem>
|
||||
<listitem><para><emphasis><filename>rpaths:</filename></emphasis>
|
||||
Checks for rpaths in the binaries that contain build system paths such
|
||||
as <filename>TMPDIR</filename>.
|
||||
If this test fails, bad <filename>-rpath</filename> options are being
|
||||
passed to the linker commands and your binaries have potential security
|
||||
issues.</para></listitem>
|
||||
<listitem><para><emphasis><filename>dev-so:</filename></emphasis>
|
||||
Checks that the <filename>.so</filename> symbolic links are in the
|
||||
<filename>-dev</filename> package and not in any of the other packages.
|
||||
In general, these symlinks are only useful for development purposes.
|
||||
Thus, the <filename>-dev</filename> package is the correct location for
|
||||
them.
|
||||
Some very rare cases do exist for dynamically loaded modules where
|
||||
these symlinks are needed instead in the main package.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis><filename>debug-files:</filename></emphasis>
|
||||
Checks for <filename>.debug</filename> directories in anything but the
|
||||
<filename>-dbg</filename> package.
|
||||
The debug files should all be in the <filename>-dbg</filename> package.
|
||||
Thus, anything packaged elsewhere is incorrect packaging.</para></listitem>
|
||||
<listitem><para><emphasis><filename>arch:</filename></emphasis>
|
||||
Checks the Executable and Linkable Format (ELF) type, bit size and endianness
|
||||
of any binaries to ensure it matches the target architecture.
|
||||
This test fails if any binaries don't match the type since there would be an
|
||||
incompatibility.
|
||||
Sometimes software, like bootloaders, might need to bypass this check.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis><filename>debug-deps:</filename></emphasis>
|
||||
Checks that <filename>-dbg</filename> packages only depend on other
|
||||
<filename>-dbg</filename> packages and not on any other types of packages,
|
||||
which would cause a packaging bug.</para></listitem>
|
||||
<listitem><para><emphasis><filename>dev-deps:</filename></emphasis>
|
||||
Checks that <filename>-dev</filename> packages only depend on other
|
||||
<filename>-dev</filename> packages and not on any other types of packages,
|
||||
which would be a packaging bug.</para></listitem>
|
||||
<listitem><para><emphasis><filename>pkgconfig:</filename></emphasis>
|
||||
Checks <filename>.pc</filename> files for any
|
||||
<filename>TMPDIR/WORKDIR</filename> paths.
|
||||
Any <filename>.pc</filename> file containing these paths is incorrect
|
||||
since <filename>pkg-config</filename> itself adds the correct sysroot prefix
|
||||
when the files are accessed.</para></listitem>
|
||||
<listitem><para><emphasis><filename>la:</filename></emphasis>
|
||||
Checks <filename>.la</filename> files for any <filename>TMPDIR</filename>
|
||||
paths.
|
||||
Any <filename>.la</filename> file continaing these paths is incorrect since
|
||||
<filename>libtool</filename> adds the correct sysroot prefix when using the
|
||||
files automatically itself.</para></listitem>
|
||||
<listitem><para><emphasis><filename>desktop:</filename></emphasis>
|
||||
Runs the <filename>desktop-file-validate</filename> program against any
|
||||
<filename>.desktop</filename> files to validate their contents against
|
||||
the specification for <filename>.desktop</filename> files.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='ref-classes-siteinfo'>
|
||||
|
|
|
|||
Loading…
Reference in New Issue