BBMASK, INSANE_SKIP, insane.bbclass, QA

markyang92·2022년 8월 16일
0

yocto

목록 보기
39/53
post-thumbnail

BBMASK


  • 기능: BBMASK.bb, .bbappend를 추가해, 해당 레시피숨길 수 있다.
    • matching되는 파일들을 무시한다.

  • 예제: 아래의 예제는, bitbakemeta-ti/recipes-misc/이하를 무시하게 한다.
BBMASK = "meta-ti/recipes-misc/"

  • 아래의 예제 처럼 사용 가능하다.
BBMASK += "/meta-ti/recipes-misc/ meta-ti/recipes-ti/packagegroup/"
BBMASK += "/meta-oe/recipes-support/"
BBMASK += "/meta-foo/.*/openldap"
BBMASK += "opencv.*\.bbappend"
BBMASK += "lzma"

INSANE_SKIP


  • 기능: recipe에서 명시된 특정 package에 대해, QA check skip !
    • 예를 들어, 레시피메인 패키지(${PN})symlink .so 파일에 대한 QA checkskip 하고 싶다면, 아래와 같이 명시한다.
    INSANE_SKIP:${PN} += "dev-so"

insane.bbclass

  • https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-insane
  • insane 클래스는 패키지 생성 프로세스에 몇 개의 step을 추가해, OpenEmbedded 빌드 시스템에서 'Output Quality Assurance Checks'가 생성되도록한다.
    • 런타임 중에 나타나는 일반적인 문제에 대해 빌드의 출력을 확인하는 다양한 검사가 수행된다.
    • Distribution policy는 일반적으로 이 클래스를 포함시킬 것인지 여부를 지정한다.
  • 특정 테스트 실패가 경고 혹은 오류 메시지를 표시하도록 sanity checks를 구성 할 수 있다.
    • 일반적으로, 새 test에 실패하면, WARNING이 생성된다.
    • 같은 test에 대해, 후속 실패 시, metadata가 in a known, good condition 일 때, ERROR 메시지를 생성한다.
  • Use the WARN_QA and ERROR_QA variables to control the behavior of these checks at the global level (i.e. in your custom distro configuration).
  • However, to skip one or more checks in recipes, you should use INSANE_SKIP. For example, to skip the check for symbolic link .so files in the main package of a recipe, add the following to the recipe. You need to realize that the package name override, in this example ${PN}, must be used:
    INSANE_SKIP:${PN} += "dev-so"

  • QA check패키지 출력물에 대한, 실제 혹은 potential problems를 발견하는 것을 명심한다.

WARN_QA, ERROR_QA 변수들

Variable                        Description
already-stripped빌드 시스템이 debug symbols를 추출하기 이전에, 생성된 바이너리가 stipped 되지 않았는지 체크한다.
이 것은 일반적으로 upstream software project에서 아웃풋 바이너리에 대해 debug symbol을 stripping하는 것이 디폴트이다.
타겟에서 디버깅하고 싶으면, -dbg 패키지를 사용하라, 이 것은 stripping이 반드시 disabled되어야 한다.
archbinary에 대해, Executable and Linkable Format(ELF) type, bit size, endianness를 체크하여, 타겟 아키텍처에 매치되게 보장한다.
이 테스트가 fail되면, 호환되지 않는 binary가 있는 것이다.
buildpathsOutput files 내부에서 빌드 호스트의 위치에 대한 path를 확인한다. 현재 이 test는 너무 많은 false positives를 trigger하여 일반적으로 enable되어 있지 않다.
build-depsDEPENDS ,명시된 RDEPENDS, task-level dependency 를 통해 지정된 build-time dependencyruntime dependency와 매치되는지 여부를 결정한다.
이는 Packaging 중에 runtime dependency가 감지되고, 추가되는 위치를 발견하는데 유용하다.
메타 데이터 내에 explicit dependency가 지정되지 않은 경우, Packaging 단계에서 dependency가 구축되었는지 확인하기에는 너무 늦기 때문에, auto-detected dependency 가 not satisfied 되어, do_rootfs() task 중에 packageimage에 설치될 때 오류가 발생할 수 있다.

e.g., update-rc.d class에서 /etc/init.d/functions를 참조하는 스크립트를 설치하는 패키지에 initscripts-functions package를 dependency를 자동으로 추가하는 경우가 있다.
이 경우, 해당 레시피가 실제로 'initscripts-function'에 대한 문제의 패키지를 explicit RDEPENDS로 걸어야한다.
compile-host-pathdo_compile task의 log를 확인하여, '빌드 호스트'상의 위치에 대한 경로를 나타내는 것이 사용되었음을 확인한다.
여러 path를 사용할 경우, build output의 host contamination 결과를 이르킬 수 있다.
debug-deps-dbg 패키지를 제외하고 모든 패키지가 -dbg패키지를 DEPENDS 하지 않도록 확인한다.
-dbg 패키지를 DEPENDS 하면, 패키징 버그의 원인이다.
debug-files-dbg 패키지를 제외하고, .debug 디렉토리를 확인한다.
.debug 파일은 -dbg 패키지에만 있어야한다.
dep-cmp패키지 (RDEPENDS, RRECOMMENDS, RSUGGESTS, RPROVIDES, RREPLACES, RCONFLICTS 변수 값) 사이 runtime dependency관계에서 invalid version comparision statements를 확인한다.
invalid comparisons는 package manager에게 전달될 때, failure 혹은 undesirable behavior를 유발할 수 있다.
desktop.desktop 파일에 대해, desktop-file-validate program을 실행해, their contents가 against the specification for .desktop files에 인증하기 위해.
dev-deps-dev, -staticdev 패키지를 제외한 패키지들이 -dev 패키지를 DEPENDS를 하지 않는지 체크한다.
위 경우, 패키징 버그를 유발할 수 있다.
dev-so-dev 패키지에서 .so 심볼릭 링크가 있는지 그리고 다른 패키지에서는 없는지 체크한다. 일반적으로 이러한 심볼릭 링크는 개발 목적에서만 유용하다. 따라서, -dev패키지가 올바른 위치이다. 아주 예외적인 케이스로, 예를들면, dynamically loaded modules, 이러한 심볼릭 링크는 메인 패키지 대신 필요하다.
empty-dirsChecks that packages are not installing files to directories that are normally expected to be empty (such as /tmp) The list of directories that are checked is specified by the QA_EMPTY_DIRS variable.
file-rdeps패키징 타임에서, 식별된 file-level 디펜던시가 만족 되는지 체크한다.
예를 들어, shell script가 #!/bin/bash로 시작된다면, /bin/bash에 디펜던시가 있는 것이다.

3개의 빌드 시스템이 OpenEmbedded build system에서 지원되지만, 오직 RPM이 directly handles file-level dependency.
QA check는 패키지 파일에서 탐지된 'file-level' dependency를 처리하기 위해, explicitly declared RDEPENDS 존재하는지 확인한다.
files-invalidChecks for FILES variable values that contain “//”, which is invalid.
host-user-contaminatedChecks that no package produced by the recipe contains any files outside of /home with a user or group ID that matches the user running BitBake. A match usually indicates that the files are being installed with an incorrect UID/GID, since target IDs are independent from host IDs. For additional information, see the section describing the do_install task.
incompatible-licenseReport when packages are excluded from being created due to being marked with a license that is in INCOMPATIBLE_LICENSE.
install-host-pathChecks the do_install log for indications that paths to locations on the build host were used. Using such paths might result in host contamination of the build output.
installed-vs-shippedReports when files have been installed within do_install but have not been included in any package by way of the FILES variable. Files that do not appear in any package cannot be present in an image later on in the build process. Ideally, all installed files should be packaged or not installed at all. These files can be deleted at the end of do_install if the files are not needed in any package.
invalid-charsChecks that the recipe metadata variables DESCRIPTION, SUMMARY, LICENSE, and SECTION do not contain non-UTF-8 characters. Some package managers do not support such characters.
invalid-packageconfigChecks that no undefined features are being added to PACKAGECONFIG. For example, any name “foo” for which the following form does not exist:

PACKAGECONFIG[foo] = "..."

laChecks .la files for any TMPDIR paths. Any .la file containing these paths is incorrect since libtool adds the correct sysroot prefix when using the files automatically itself.
ldflagsEnsures that the binaries were linked with the LDFLAGS options provided by the build system. If this test fails, check that the LDFLAGS variable is being passed to the linker command.
libdirChecks for libraries being installed into incorrect (possibly hardcoded) installation paths. For example, this test will catch recipes that install /lib/bar.so when ${base_libdir} is “lib32”. Another example is when recipes install /usr/lib64/foo.so when ${libdir} is “/usr/lib”.
libexecChecks if a package contains files in /usr/libexec. This check is not performed if the libexecdir variable has been set explicitly to /usr/libexec.
packages-listChecks for the same package being listed multiple times through the PACKAGES variable value. Installing the package in this manner can cause errors during packaging.
perm-configReports lines in fs-perms.txt that have an invalid format.
perm-lineReports lines in fs-perms.txt that have an invalid format.
perm-linkReports lines in fs-perms.txt that specify ‘link’ where the specified target already exists.
permsCurrently, this check is unused but reserved.
pkgconfigChecks .pc files for any TMPDIR/WORKDIR paths. Any .pc file containing these paths is incorrect since pkg-config itself adds the correct sysroot prefix when the files are accessed.
pkgnameChecks that all packages in PACKAGES have names that do not contain invalid characters (i.e. characters other than 0-9, a-z, ., +, and -).
pkgv-undefinedChecks to see if the PKGV variable is undefined during do_package.
pkgvarcheckChecks through the variables RDEPENDS, RRECOMMENDS, RSUGGESTS, RCONFLICTS, RPROVIDES, RREPLACES, FILES, ALLOW_EMPTY, pkg_preinst, pkg_postinst, pkg_prerm and pkg_postrm, and reports if there are variable sets that are not package-specific. Using these variables without a package suffix is bad practice, and might unnecessarily complicate dependencies of other packages within the same recipe or have other unintended consequences.
pn-overridesChecks that a recipe does not have a name (PN) value that appears in OVERRIDES. If a recipe is named such that its PN value matches something already in OVERRIDES (e.g. PN happens to be the same as MACHINE or DISTRO), it can have unexpected consequences. For example, assignments such as FILES:${PN} = "xyz" effectively turn into FILES = "xyz".
rpathsChecks for rpaths in the binaries that contain build system paths such as TMPDIR. If this test fails, bad -rpath options are being passed to the linker commands and your binaries have potential security issues.
split-stripReports that splitting or stripping debug symbols from binaries has failed.
staticdevChecks for static library files (*.a) in non-staticdev packages.
symlink-to-sysrootChecks for symlinks in packages that point into TMPDIR on the host. Such symlinks will work on the host, but are clearly invalid when running on the target.
textrelChecks for ELF binaries that contain relocations in their .text sections, which can result in a performance impact at runtime. See the explanation for the ELF binary message in “QA Error and Warning Messages” for more information regarding runtime performance issues.
unlisted-pkg-licsChecks that all declared licenses applying for a package are also declared on the recipe level (i.e. any license in LICENSE:* should appear in LICENSE).
useless-rpathsChecks for dynamic library load paths (rpaths) in the binaries that by default on a standard system are searched by the linker (e.g. /lib and /usr/lib). While these paths will not cause any breakage, they do waste space and are unnecessary.
var-undefinedReports when variables fundamental to packaging (i.e. WORKDIR, DEPLOY_DIR, D, PN, and PKGD) are undefined during do_package.
version-going-backwardsIf Build History is enabled, reports when a package being written out has a lower version than the previously written package under the same name. If you are placing output packages into a feed and upgrading packages on a target system using that feed, the version of a package going backwards can result in the target system not correctly upgrading to the “new” version of the package.

Note
This is only relevant when you are using runtime package management on your target system.

xorg-driver-abiChecks that all packages containing Xorg drivers have ABI dependencies. The xserver-xorg recipe provides driver ABI names. All drivers should depend on the ABI versions that they have been built against. Driver recipes that include xorg-driver-input.inc or xorg-driver-video.inc will automatically get these versions. Consequently, you should only need to explicitly add dependencies to binary driver recipes.
profile
pllpokko@alumni.kaist.ac.kr

0개의 댓글