11 质量检查错误和警告消息

11 简介

构建配方时,OpenEmbedded 构建系统对输出执行各种质量检查(QA), 确保发现并报告常见问题。有时,为新软件创建配方后可以顺利构建; 如果不能,或者构建任何软件时出现质量检查问题,可能需要一些时间解决。

虽然直接忽略消息甚至禁用检查很有吸引力,但最好尝试解决报告的问题。 本章列出质量检查消息,并简要说明可能遇到的问题,帮助正确处理。

下一节列出默认配置下的质量检查错误和警告消息。 每个条目包含消息或错误的形式及其说明。

备注

  • 每条消息末尾的方括号中,列出对应检查的名称, 与“insane”一节中的名称一致。

  • 此列表仅涉及质量检查,不涵盖构建中可能出现的全部错误和警告。

  • 某些检查默认禁用,因此本列表也不包括所有可能的质量检查错误和警告。

11 错误和警告

11.2.1 already-stripped

File '<file>' from <recipename> was already stripped, this will prevent future debugging! [already-stripped]

构建系统提取调试符号之前,生成的二进制文件已经被剥离。 上游软件项目常默认剥离输出文件的调试符号。 要通过 -dbg 软件包在目标上调试,必须禁用上游的剥离操作。

具体方式取决于软件使用的构建系统,可能只需添加 configure 选项, 也可能需要修改构建脚本。后一种情况下,应查找“strip”“STRIP”, 或链接器命令行中的“-s”“-S”选项。 这些选项也可能通过编译器命令行中的“-Wl,”前缀传入。

备注

在此禁用剥离,不表示最终软件包中的二进制文件会保留全部符号。 OpenEmbedded 构建系统将调试符号拆分到 -dbg 包后, 仍会从二进制文件中剥离这些符号。

11.2.2 arch

  • Architecture did not match (<file_arch>, expected <machine_arch>) in <file> [arch]

    默认情况下,OpenEmbedded 构建系统检查所有二进制文件的 ELF 类型、 位数和字节序,确保与目标架构匹配。不匹配意味着不兼容,检查会失败。 这可能表示使用了错误的编译器或编译选项。 引导加载程序等软件有时需要绕过检查。 如果报错文件是无需在目标操作系统内执行的固件, 或将在设备的独立处理器上运行,可将“arch”加入该软件包的 INSANE_SKIP。 也可以检查 do_compile 日志,确认编译器选项正确。

  • Bit size did not match (<file_bits>, expected <machine_bits>) in <file> [arch]

    默认情况下,OpenEmbedded 构建系统检查所有二进制文件的 ELF 类型、 位数和字节序,确保与目标架构匹配。不匹配意味着不兼容,检查会失败。 这可能表示使用了错误的编译器或编译选项。 引导加载程序等软件有时需要绕过检查。 如果报错文件是无需在目标操作系统内执行的固件, 或将在设备的独立处理器上运行,可将“arch”加入该软件包的 INSANE_SKIP。 也可以检查 do_compile 日志,确认编译器选项正确。

  • Endianness did not match (<file_endianness>, expected <machine_endianness>) in <file> [arch]

    默认情况下,OpenEmbedded 构建系统检查所有二进制文件的 ELF 类型、 位数和字节序,确保与目标架构匹配。不匹配意味着不兼容,检查会失败。 这可能表示使用了错误的编译器或编译选项。 引导加载程序等软件有时需要绕过检查。 如果报错文件是无需在目标操作系统内执行的固件, 或将在设备的独立处理器上运行,可将“arch”加入该软件包的 INSANE_SKIP。 也可以检查 do_compile 日志,确认编译器选项正确。

11.2.3 build-deps

<packagename1> rdepends on <packagename2>, but it isn't a build dependency? [build-deps]

指定的两个软件包存在运行时依赖,但配方没有显式声明, 构建系统因而无法确保该依赖已满足。 通常是因为 RDEPENDS 在打包阶段才根据软件包内容自动添加, 而没有提前声明。多数情况下,应修改配方,为该依赖添加显式 RDEPENDS。

11.2.4 buildpaths

File <filename> in package <packagename> contains reference to TMPDIR [buildpaths]

此检查确保输出文件不包含 TMPDIR 等构建系统路径。 这些路径既会向目标泄漏构建系统配置,也会妨碍二进制可复现性, 因为构建配置变化会导致输出变化。

通常,路径通过软件配置或编译过程中的某种机制进入输出。 应先确定检测到的路径如何进入输出,再解决问题。 有时需要修改脚本或代码,使用相对路径而不是绝对路径, 或从运行时配置、环境变量获取路径。

11.2.5 configure-gettext

AM_GNU_GETTEXT used but no inherit gettext [configure-gettext]

如果配方构建的软件使用 automake,且相关文件包含 AM_GNU_GETTEXT 指令, 配方就必须通过 inherit gettext 确保构建时可使用 gettext。 缺少该声明会触发检查;添加 inherit gettext 即可消除警告。

11.2.6 configure-unsafe

This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities. Rerun configure task after fixing this. [configure-unsafe]

do_configure 日志表明构建搜索了主机路径中的文件, 这不适用于交叉编译。请在指定日志中查找 “is unsafe for cross-compilation”或“CROSS COMPILE Badness”。

11.2.7 debug-deps

<packagename> rdepends on <debug_packagename> [debug-deps]

指定的非 dbg 软件包(名称不以 -dbg 结尾)依赖一个 dbg 包。 dbg 包包含调试符号,通常通过以下方式引入:

此依赖可能是自动添加的,因为 dbg 包错误包含了不应包含的文件, 例如不是符号链接的 .so 文件;也可能是手动添加的, 例如加入 RDEPENDS。

11.2.8 debug-files

non debug package contains .debug directory: <packagename> path <path> [debug-files]

指定软件包包含 .debug 目录,而该目录只应出现在 -dbg 包中。 如果添加的路径包含 .debug,却未显式将其归入 -dbg 包, 就可能出现此问题。应将目录显式加入 FILES:${PN}-dbg。 更多信息见 FILES。

11.2.9 dep-cmp

<var>:<packagename> is invalid: <comparison> (<value>)   only comparisons <, =, >, <=, and >= are allowed [dep-cmp]

向依赖变量(RDEPENDS、RRECOMMENDS、RSUGGESTS、 RPROVIDES、RREPLACES 或 RCONFLICTS)添加带版本的 依赖关系时,只能使用消息列出的比较运算符。 请相应修改版本依赖值。

11.2.10 dev-deps

<packagename> rdepends on <dev_packagename> [dev-deps]

指定的非 dev 软件包(名称不以 -dev 结尾)依赖一个 dev 包。 dev 包包含开发头文件,通常通过以下方式引入:

此依赖可能是自动添加的,因为 dev 包错误包含了不应包含的文件, 例如不是符号链接的 .so 文件;也可能是手动添加的, 例如加入 RDEPENDS。

11.2.11 desktop

"Desktop file issue: ... [desktop]

对所有 .desktop 文件运行 desktop-file-validate, 验证其内容是否符合 .desktop 文件规范。

11.2.12 dev-so

non -dev/-dbg/nativesdk- package contains symlink .so: <packagename> path '<path>' [dev-so]

作为符号链接的 .so 文件仅用于开发,应放入 -dev 包。 如果向非开发包添加 *.so* 而不是 *.so.*,就可能出现此问题。 修改 FILES,必要时也修改 PACKAGES, 使指定的 .so 文件归入适当的 -dev 包。

11.2.13 empty-dirs

<packagename> installs files in <path>, but it is expected to be empty [empty-dirs]

指定软件包向通常应为空的目录(例如 /tmp)安装了文件。 这些文件可能更适合安装到其他位置,或者根本不应安装。 通常通过修改 do_install 任务或函数解决。

11.2.14 file-rdeps

<packagename> requires <files>, but no providers in its RDEPENDS [file-rdeps]

检查发现指定软件包对所列文件存在文件级依赖, 但 RDEPENDS 中没有对应的显式条目。 如果运行时需要这些文件,应在配方中声明 RDEPENDS, 确保提供文件的软件包得到构建。

11.2.15 files-invalid

FILES variable for package <packagename> contains '//' which is invalid. Attempting to fix this but you should correct the metadata. [files-invalid]

Unix 路径中的“//”无效。 请修正 FILES 中所有这样的字符串,只保留单个“/”。

11.2.16 host-user-contaminated

<package name>: <path> is owned by gid/uid <gid/uid>, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated]

检查配方生成的软件包是否在 /home 之外包含 UID 或 GID 与运行 BitBake 的用户相同的文件。 目标 ID 独立于主机 ID,因此匹配通常意味着安装时使用了错误的 UID/GID。 更多信息见 do_install 任务说明。

11.2.17 infodir

The /usr/share/info/dir file is not meant to be shipped in a particular package. [infodir]

不应将 /usr/share/info/dir 打包。 请在配方的 do_install 或 do_install:append 中添加:

rm ${D}${infodir}/dir

11.2.18 installed-vs-shipped

<recipename>: Files/directories were installed but not shipped in any package [installed-vs-shipped]

文件在 do_install 中已安装,但没有通过 FILES 归入任何软件包。未进入任何软件包的文件,后续也不会出现在镜像中。 需要采取以下一种方式:

  • 将文件加入目标软件包的 FILES, 例如主软件包使用 FILES:${PN}。

  • 如果所有软件包都不需要这些文件,在 do_install 末尾删除它们。

11.2.19 incompatible-license

Excluding <package> from packaging as it has incompatible license(s): <license> [incompatible-license]

当软件包因许可证列于 INCOMPATIBLE_LICENSE 而被排除、不予生成时,报告此消息。

11.2.20 invalid-chars

<variable> has non <envoding> characters [invalid-chars]

检查配方元数据变量 DESCRIPTION、SUMMARY、 LICENSE 和 SECTION 是否包含非 UTF-8 字符。 某些软件包管理器不支持这些字符。

11.2.21 invalid-packageconfig

<package>: invalid PACKAGECONFIG(s): <configs> [invalid-packageconfig]

检查 PACKAGECONFIG 中是否添加了未定义的功能。 例如,添加了“foo”,却不存在以下定义:

PACKAGECONFIG[foo] = "..."

11.2.22 la

<file> failed sanity test (workdir) in path <path> [la]

指定 .la 文件包含 TMPDIR 路径。 这是不正确的,因为 libtool 使用这些文件时会自行添加正确的系统根目录前缀。

11.2.23 ldflags

File '<file>' in package '<package>' doesn't have GNU_HASH (didn't pass LDFLAGS?) [ldflags]

这表示配方生成的二进制文件没有使用构建系统提供的 LDFLAGS 链接。 请确认 LDFLAGS 已传给链接器命令。 常见的临时解决方法是在配方中通过 TARGET_CC_ARCH 传入 LDFLAGS,如下所示:

TARGET_CC_ARCH += "${LDFLAGS}"

11.2.24 libdir

<packagename>: found library in wrong location [libdir]

指定文件可能安装到错误的路径,路径可能被硬编码。 例如,${base_libdir} 为“lib32”时却安装到 /lib/bar.so, 或 ${libdir} 为“/usr/lib”时却安装到 /usr/lib64/foo.so, 都会被检测到。偶尔可能误报,此时可将“libdir”加入软件包的 INSANE_SKIP。

11.2.25 libexec

<packagename>: <path> is using libexec please relocate to <libexecdir> [libexec]

指定软件包在 /usr/libexec 中包含文件, 而发行版配置的 <libexecdir> 是其他路径。 <libexecdir> 默认为 $prefix/libexec,但可以修改,例如改为 ${libdir}。

11.2.26 mime

package contains mime types but does not inherit mime: <packagename> path '<file>' [mime]

指定软件包包含 MIME 类型文件,即 ${datadir}/mime/packages 中的 .xml 文件,却没有继承确保正确安装这些文件的 mime 类。 应在配方中添加 inherit mime;如果不需要这些文件, 则在 do_install 阶段删除。

11.2.27 mime-xdg

package contains desktop file with key 'MimeType' but does not inherit mime-xdg: <packagename> path '<file>' [mime-xdg]

指定软件包包含带“MimeType”键的 .desktop 文件, 却没有继承激活此功能所需的 mime-xdg 类。 应在配方中添加 inherit mime;如果不需要这些文件, 则在 do_install 阶段删除。

11.2.28 missing-update-alternatives

<recipename>: recipe defines ALTERNATIVE:<packagename> but doesn't inherit update-alternatives. This might fail during do_rootfs later! [missing-update-alternatives]

此检查确保设置了 ALTERNATIVE 的配方也继承 update-alternatives,以正确设置替代项。 出现此消息时,请添加 inherit update-alternatives, 或在不需要时移除对该变量的引用。

11.2.29 packages-list

<packagename> is listed in PACKAGES multiple times, this leads to packaging errors. [packages-list]

软件包名称只能在 PACKAGES 中出现一次。 尝试添加已经存在于该变量中的软件包时,可能收到此错误。

11.2.30 patch-fuzz

Fuzz detected: <patch output> [patch-fuzz]

此检查查找 do_patch 应用补丁时发生“模糊匹配”的证据。 模糊匹配指 patch 为应用补丁而忽略部分上下文行。考虑以下示例。

待应用补丁:

--- filename
+++ filename
 context line 1
 context line 2
 context line 3
+newly added line
 context line 4
 context line 5
 context line 6

原始源码:

different context line 1
different context line 2
context line 3
context line 4
different context line 5
different context line 6

使用模糊匹配应用补丁后的结果:

different context line 1
different context line 2
context line 3
newly added line
context line 4
different context line 5
different context line 6

新增行可能实际上被插入了完全错误的位置, 或原始源码中已存在该行,结果又重复添加了一次。 当第 3、4 行为空,或仅包含 #endif、} 等常见内容时,尤其容易发生。 根据代码情况,错误应用补丁的文件仍可能无报错地通过编译。

如何消除补丁模糊匹配警告

按照警告说明使用 devtool。先将源码解包到工作区:

devtool modify <recipe>

这会应用全部补丁,在工作区中创建对应提交,并更新补丁上下文。

随后替换配方层中的补丁:

devtool finish --force-patch-refresh <recipe> <layer_path>

接下来必须审查补丁更新,最好使用并排差异比较工具,确保:

  1. 补丁应用到文件中的正确位置;

  2. 没有引入重复行,也没有执行已不再必要的操作。

还可以查看 devtool 工作区中的打补丁后源码,通常位于 <build_dir>/workspace/sources/<recipe>/,进一步确认。

审查完成后,可以在层中创建并发布包含这些上下文更新的提交。 Devtool 也可能刷新补丁的其他内容,这些变更可以丢弃。

11.2.31 patch-status

  • Missing Upstream-Status in patch <patchfile> Please add according to <url> [patch-status]

    指定补丁文件头缺少 Upstream-Status, 该值用于跟踪补丁是否已发送上游、是否已合并等状态。

    更多信息请参阅《Yocto Project 与 OpenEmbedded 贡献者指南》的 “补丁上游状态”一节。

  • Malformed Upstream-Status in patch <patchfile> Please correct according to <url> [patch-status]

    指定补丁文件头的 Upstream-Status 值无效,必须符合特定格式。 更多信息见上面的“Missing Upstream-Status”条目。

11.2.32 pep517-backend

inherits setuptools3 but has pyproject.toml with <build backend>, use the correct class [pep517-backend]

检查继承 setuptools3 的配方是否使用符合 PEP517 的后端。

11.2.33 perllocalpod

<packagename> contains perllocal.pod (<files>), should not be installed [perllocalpod]

perllocal.pod 是本地安装模块的索引,不应由发行版软件包安装。 cpan* 已设置 NO_PERLLOCAL, 阻止多数 Perl 配方生成它,但直接使用 MakeMaker 的配方可能处理不正确。 此检查确保所有软件包均不包含该文件, 避免多个软件包同时提供它,导致一起安装时冲突。

11.2.34 perm-config

Fixup Perms: invalid config line <line> [perm-config]

报告 fs-perms.txt 中格式无效的行。

11.2.35 perm-line

Fixup perms: <config> invalid line: <line> [perm-line]

报告 fs-perms.txt 中格式无效的行。

11.2.37 perms

此检查目前未使用,但予以保留。

11.2.38 pkgconfig

<file> failed sanity test (tmpdir) in path <path> [pkgconfig]

指定 .pc 文件包含 TMPDIR/WORKDIR 路径。 这是不正确的,因为 pkg-config 访问这些文件时会自行添加正确的系统根目录前缀。

11.2.39 pkgname

<packagename> doesn't match the [a-z0-9.+-]+ regex [pkgname]

OpenEmbedded 构建系统约定软件包名称全部小写,且只允许有限的字符集, 有时软件包管理器本身也会强制此要求。 配方名称不符,或向 PACKAGES 添加不符合约定的名称,都会产生此错误。 请重命名配方,或相应修改 PACKAGES 中的软件包名称。

11.2.40 pkgvarcheck

  • <recipefile>: Variable <variable> is set as not being package specific, please fix this. [pkgvarcheck]

    某些变量(RDEPENDS、RRECOMMENDS、RSUGGESTS、 RCONFLICTS、RPROVIDES、RREPLACES、FILES、 pkg_preinst、pkg_postinst、pkg_prerm、pkg_postrm 和 ALLOW_EMPTY)必须针对具体软件包设置。 应使用带软件包名称的覆盖形式,例如 RDEPENDS:${PN} = "value", 而不是 RDEPENDS = "value"。请修正配方中对此类变量的赋值。

  • recipe uses DEPENDS:${PN}, should use DEPENDS [pkgvarcheck]

    此检查查找错误的 DEPENDS:${PN} 设置。 DEPENDS 作用于整个配方,不能针对某个软件包指定, 这种赋值也不会实际生效。请改为设置 DEPENDS。

11.2.41 pn-overrides

Recipe <recipefile> has PN of "<recipename>" which is in OVERRIDES, this can result in unexpected behavior. [pn-overrides]

指定配方的名称值(PN)也出现在 OVERRIDES 中。 例如 PN 恰好与 MACHINE 或 DISTRO 相同, 会产生意外后果:FILES:${PN} = "xyz" 实际等同于 FILES = "xyz"。 请重命名配方;如果显式设置了 PN,则修改其值以避免冲突。 更多信息见 FILES。

11.2.42 shebang-size

<packagename>: <file> maximum shebang size exceeded, the maximum size is 128. [shebang-size]

检查脚本的 shebang 行(第一行的 #!)是否超过 128 个字符。 根据操作系统不同,超长可能导致运行时错误。 出现此消息时,可能需要为脚本打补丁,缩短该行以避免运行问题。

11 共享库提供者

<oldpackage>-<oldpkgversion> was registered as shlib provider for <library>, changing it to <newpackage>-<newpkgversion> because it was built later

此消息表示 <oldpackage> 和 <newpackage> 同时提供指定共享库。 配方重命名时出现此消息属于预期行为。 否则,可能是某个私有库版本被错误识别为公共库的提供者。 此时应在提供该私有版本的配方中,将库的 .so 文件名加入 PRIVATE_LIBS。

11.2.44 space-around-equal

<filename>:<line number> has a lack of whitespace around the assignment: '<assignment>'

此警告表示赋值符号周围缺少空格。

例如,以下赋值会产生警告:

FOO="bar"
FOO= "bar"
FOO ="bar"

应改为:

FOO = "bar"

11.2.45 src-uri-bad

  • <recipename>: SRC_URI uses unstable GitHub archives [src-uri-bad]

    GitHub 提供的归档压缩包可能随时重新生成, 因此未来文件签名可能与 SRC_URI 中的校验和不一致,导致构建失败。 建议使用官方发布压缩包,或改为从实际 Git 仓库获取对应修订版本。

  • SRC_URI uses PN not BPN [src-uri-bad]

    如果 SRC_URI 需要引用配方名称,应使用 ${BPN} 而不是 ${PN}。后者会随同一配方的变体变化, 例如使用 BBCLASSEXTEND 或 multilib 时。 检查发现 SRC_URI 中引用 ${PN} 就会失败,请改为 ${BPN}。

11.2.46 staticdev

non -staticdev package contains static .a library: <packagename> path '<path>' [staticdev]

静态 .a 库文件应归入 -staticdev 包。 修改 FILES,必要时也修改 PACKAGES, 使指定文件进入适当的 -staticdev 包。

11 配方命名

Recipe <recipe> appears native/nativesdk but is not, should inherit native/nativesdk

检查配方名称和配方类是否匹配:*-native 配方应继承 native,nativesdk-* 配方应继承 nativesdk。

11.2.49 rpaths

package <packagename> contains bad RPATH <rpath> in file <file> [rpaths]

指定二进制文件的动态库加载路径(rpath)包含 TMPDIR 等构建系统路径。这些路径在目标上不正确,还可能造成安全问题。 请检查 do_compile 日志中是否向链接器传入了错误的 -rpath。 根据软件构建系统不同,可能有 configure 选项可以完全禁用 rpath。

11.2.50 textrel

ELF binary '<file>' has relocations in .text [textrel]

指定 ELF 二进制文件的 .text 节存在重定位,可能影响运行时性能。

通常可通过向编译器命令行添加“-fPIC”或“-fpic”解决。 例如,软件构建时读取 CFLAGS,就可以在配方中添加:

CFLAGS:append = " -fPIC"

有关运行时文本重定位的更多信息,见 https://www.akkadia.org/drepper/textrelocs.html。

11.2.51 unhandled-features-check

<recipename>: recipe doesn't inherit features_check [unhandled-features-check]

此检查确保使用 features_check 支持的变量 (例如 REQUIRED_DISTRO_FEATURES)时, 配方同时继承 features_check,使要求真正生效。 请添加 inherit features_check,或在不需要时移除该变量引用。

11.2.52 unimplemented-ptest

<tool> tests detected [unimplemented-ptest]

检查软件包源码是否包含上游提供的测试,并在存在时检查配方是否实现了 ptest。 请参阅《Yocto Project 测试环境手册》的 “使用 ptest 测试软件包”一节, 以及“ptest”一节。

11.2.53 unknown-configure-option

<recipe>: configure was passed unrecognized options: <options> [unknown-configure-option]

configure 脚本报告无法识别指定选项。 这些选项可能以前有效、后来被删除,也可能添加时有误,应改用另一个选项。 如果不确定,请查看上游构建文档、./configure --help 输出, 以及上游变更日志或发行说明。 确定正确修改方式后,相应更新 EXTRA_OECONF、 PACKAGECONFIG_CONFARGS 或各 PACKAGECONFIG 选项的值。

11.2.54 unlisted-pkg-lics

LICENSE:<packagename> includes licenses (<licenses>) that are not listed in LICENSE [unlisted-pkg-lics]

配方的 LICENSE 应是该配方产生的全部软件包许可证的超集。 换言之,LICENSE:* 中的每个许可证都应出现在 LICENSE 中。

11.2.55 useless-rpaths

<packagename>: <file> contains probably-redundant RPATH <rpath> [useless-rpaths]

指定二进制文件的动态库加载路径(rpath)包含标准系统上链接器默认搜索的目录, 例如 /lib 和 /usr/lib。这些路径不会破坏功能,但没有必要且浪费空间。 根据软件构建系统不同,可能有 configure 选项可以完全禁用 rpath。

11.2.56 usrmerge

<packagename> package is not obeying usrmerge distro feature. /<path> should be relocated to /usr. [usrmerge]

如果 DISTRO_FEATURES 包含 usrmerge, 此检查确保没有软件包将文件安装到根目录下的 /bin、/sbin、 /lib 或 /lib64。 出现此消息表明 do_install 或它调用的构建过程 (例如 make install)使用了硬编码路径, 而非为此设置的 bindir、sbindir 等变量,应改为使用这些变量。

11.2.57 version-going-backwards

Package version for package <package> went backwards which would break package feeds (from <version2> to <version1>) [version-going-backwards]

启用 buildhistory 时, 如果当前输出的软件包版本低于此前同名软件包版本,就会报告此消息。 如果将输出软件包放入软件包源,并使用该源升级目标系统, 版本倒退可能使目标无法正确升级到“新”版本。

备注

此问题只与在目标系统上使用运行时软件包管理有关。

11.2.58 virtual-slash

<variable> is set to <value> but the substring 'virtual/' holds no meaning in this context. It only works for build time dependencies, not runtime ones. It is suggested to use 'VIRTUAL-RUNTIME_' variables instead. [virtual-slash]

virtual/ 是用于构建上下文的约定,即 PROVIDES 和 DEPENDS, 而不适用于 RPROVIDES 和 RDEPENDS 等运行时上下文。 后者应改用 VIRTUAL-RUNTIME 变量。

11.2.59 xorg-driver-abi

Package <packagename> contains Xorg driver (<driver>) but no xorg-abi- dependencies [xorg-driver-abi]

指定软件包包含 Xorg 驱动,但缺少对应 ABI 软件包依赖。 xserver-xorg 配方提供驱动 ABI 名称,所有驱动都应依赖构建时使用的 ABI 版本。 包含 xorg-driver-input.inc 或 xorg-driver-video.inc 的驱动配方 会自动获得这些版本,因此通常只需为二进制驱动配方显式添加依赖。

11 配置和禁用质量检查

可以通过 WARN_QA 和 ERROR_QA 全局配置质量检查, 使特定检查失败时分别产生警告或错误。 也可以在单个配方中使用 INSANE_SKIP 禁用检查。 有关操作方式,请参阅“insane”一节。

备注

质量检查用于发现打包输出中真实或潜在的问题,禁用时务必谨慎。