recipe·package·image는 서로 다른 단위입니다
| 이름 | 역할 | 흔한 오해 |
|---|---|---|
| recipe (.bb) | 소스를 가져오고 빌드·설치·패키징하는 metadata와 task를 정의합니다. | recipe 하나가 항상 패키지 하나를 만든다고 생각합니다. |
| package | 설치할 파일과 runtime dependency 등을 묶는 단위입니다. | 컴파일 성공한 모든 파일이 최종 image에 들어간다고 생각합니다. |
| image recipe | 어떤 패키지와 기능을 rootfs에 넣을지 정합니다. | kernel recipe만 바꾸면 rootfs의 모든 내용도 바뀐다고 생각합니다. |
| MACHINE / DISTRO | 하드웨어 대상과 배포 정책 등의 구성을 선택합니다. | 둘을 모두 보드 이름 정도로 취급합니다. |
BitBake는 단순히 shell 명령을 위에서 아래로 한 번씩 실행하는 스크립트 실행기가 아닙니다. metadata와 의존성으로 task graph를 구성하고, 재사용할 수 있는 결과가 있으면 sstate 등을 활용합니다. Yocto의 빌드 구조
파일이 어느 단계에서 없어졌는지 찾습니다
- fetch → unpack → patch
정해진 source revision을 가져와 작업 소스를 준비합니다.
configure·compile task의 입력이 됩니다.
- configure → compile → install
구성하고 빌드한 뒤 recipe의 staging 영역인 ${D}에 설치합니다.
패키지 분리 규칙을 적용합니다.
- package → package_write_*
파일을 패키지로 나누고 선택한 형식의 패키지를 만듭니다.
image에 선택된 패키지를 설치합니다.
- rootfs → image
최종 rootfs를 구성하고 지정한 파일 시스템·이미지 형식을 만듭니다.
Wic을 사용하면 파티션 배치까지 구성합니다.
- 배포용 이미지
보드가 기대하는 부트 영역·rootfs 등의 배치를 확인합니다.
→는 대표적인 의존 흐름입니다. 실제 task graph에는 native tool·sysroot·패키지 의존성 등이 더 있고 독립 task는 병렬로 진행될 수 있습니다.
do_install이 성공했는데 제품에서 파일이 없다면 ${D}에 설치됐는지, FILES 규칙에 잡혔는지, 어느 package로 나뉘었는지, 그 package가 image에 포함됐는지를 차례로 봅니다. task별 역할
변수가 무엇을 선택하는지 읽습니다
IMAGE_INSTALL:append = " example-tool"
IMAGE_FSTYPES += "wic"
WKS_FILE = "example-layout.wks"| 줄 | 설명 |
|---|---|
| 1 | image에 example-tool 패키지를 추가하는 교육용 예입니다. example-tool이라는 recipe가 존재한다는 보장은 없습니다. append 문자열 앞의 공백은 기존 항목과 분리하는 데 필요합니다. |
| 2 | 이미지 출력 형식에 wic을 더합니다. 해당 BSP와 image 구성이 지원해야 합니다. |
| 3 | Wic이 사용할 파티션 배치 파일을 선택합니다. 실제 프로젝트에 존재하는 파일이어야 합니다. |
예전 metadata의 VAR_append와 최근 override 문법의 VAR:append는 적용 버전을 확인해야 합니다. DEPENDS는 빌드에 필요한 recipe 측 의존성, RDEPENDS:${PN}은 생성 패키지의 runtime 의존성을 표현합니다. 둘을 같은 이름 목록으로 기계적으로 바꾸면 안 됩니다. 변수 정의 override 문법 변경
Wic은 rootfs의 내용과 디스크 배치를 연결합니다
rootfs tar나 ext4 파일을 만들었다고 부트로더가 요구하는 디스크 배치까지 완료된 것은 아닙니다. Wic의 kickstart 파일은 파티션의 source·크기·정렬·파일 시스템 등을 지정합니다. 부트로더를 파티션 표에 없는 raw 영역에 쓰는 BSP도 있으므로, 다른 보드의 offset을 그대로 복사하면 안 됩니다. Wic 이미지 생성
bitbake -e example-image
bitbake-layers show-layers
bitbake-layers show-appends읽기·조사용 명령 예입니다. 첫 명령의 결과에서 최종 IMAGE_INSTALL, IMAGE_FSTYPES, WKS_FILE과 변수 변경 이력을 확인합니다. 이미지가 달라진 이유를 찾을 때 source revision뿐 아니라 layer revision·local.conf·MACHINE·DISTRO·적용된 bbappend도 함께 기록해야 합니다.
모듈 적재와 설치 후처리는 빌드 성공과 다릅니다
module 클래스의 빌드, 패키지의 rootfs 포함, 부팅 때 적재는 별개입니다. KERNEL_MODULE_AUTOLOAD 설정도 실제 적재·장치 동작의 검증을 대신하지 않습니다. 외부 모듈 · 자동 적재 설정
5.0에서 실패한 pkg_postinst는 do_rootfs 오류이지 첫 부팅 실행 예약이 아닙니다. 꼭 타깃에서 할 작업은 pkg_postinst_ontarget 같은 명시적 경로로 구분합니다. 읽기 전용 rootfs는 첫 부팅 때 rootfs를 쓰는 처리에 의존할 수 없습니다. 빌드용 도구는 PACKAGE_WRITE_DEPS도 확인합니다. 후처리 실행 환경
English
Building a module, including its package, and loading it at boot are separate checks; none proves device operation. In Yocto 5.0, post-install failure is a rootfs build error, not automatic deferral. Target-only work needs an explicit mechanism and must respect read-only rootfs constraints.
공급자 이름과 가져온 소스의 정체를 구분합니다
PROVIDES·PREFERRED_PROVIDER는 빌드할 recipe 쪽, RPROVIDES·RDEPENDS는 설치 패키지 쪽입니다. PREFERRED_VERSION은 버전 선택이며 공급자 선택을 대체하지 않습니다. packagegroup도 이미지에 포함돼야 그 패키지 의존성이 설치 대상이 됩니다. 공급자 변수 · packagegroup과 이미지
do_fetch, do_unpack, do_patch는 다운로드·작업 트리·변경 적용 단계입니다. 다운로드 캐시를 재사용하거나 pre-mirror, 원본 URI, mirror에서 소스를 구해도 의도한 revision과 checksum의 확인은 별도입니다. URI 방식이 fetcher를 고르며 Git 전송 프로토콜과는 구별됩니다. 소스를 받았다는 사실은 라이선스 검토가 아닙니다. BitBake 2.8 fetching
English
Recipe providers and runtime package aliases belong to different dependency graphs; packagegroups still need image inclusion. Fetching, unpacking and patching are distinct. Cache or mirror availability does not establish the intended revision, archive integrity or license review; fetcher selection and transport protocol are separate choices.
stamp·sstate와 최종 변수값을 따로 확인합니다
stamp는 현재 빌드 상태에서 태스크 재실행이 필요한지 판단하는 표식입니다. sstate는 대응하는 setscene 경로로 산출물을 복원합니다. 모든 태스크가 같은 방식으로 재사용되는 것은 아닙니다. 입력·의존성 서명이 맞는지와 보드에서 동작하는지는 별도 확인입니다. stamp와 공유 상태
virtual/는 런타임 RDEPENDS·RPROVIDES에서 특별한 선택 기능이 없습니다. override의 : 전환은 3.4 Honister이며, 모든 밑줄을 바꾸는 규칙은 아닙니다. 예를 들어 PREFERRED_VERSION_ 뒤의 recipe 이름은 유지합니다. :append는 공백을 자동 삽입하지 않고 :remove는 확장 시 마지막에 적용됩니다. Honister 변경점 · 연산자 의미
English
A stamp and restored sstate outputs answer different reuse questions, not hardware validation. Runtime aliases gain no special meaning from virtual/. Colon overrides arrived in Honister 3.4; not every underscore is an override. Append needs explicit spacing, and removal is applied last at expansion.
커널 변경은 선택된 recipe의 입력으로 남깁니다
레이어 등록, .bbappend의 recipe 매칭, 최종 커널 설정은 각각 확인합니다. configuration fragment·적합한 defconfig·소스 patch를 레이어에 보존하고 SRC_URI와 검색 경로로 연결합니다. 작업 디렉터리의 임시 수정만으로 재현 가능한 변경이 되지는 않습니다. 최종 .config와 patch 적용 결과를 대상 BSP에서 대조합니다. 레이어와 append · 커널 설정 변경
English
Layer registration does not prove append matching or the final kernel configuration. Preserve fragments and patches as recipe inputs, then verify the resulting configuration and applied patches for the selected BSP. A temporary build-tree edit alone is not a reproducible change.
rootfs 여유·파티션·압축 크기는 서로 다릅니다
IMAGE_ROOTFS_EXTRA_SPACE는 rootfs 이미지의 추가 여유를 KiB 단위로 지정합니다. 이 값이 SD/eMMC 전체 용량을 배정하거나 배포 뒤 파티션을 자동 확장하지는 않습니다. .wks의 파티션 배치, 압축된 .wic.zst 파일 크기, 실제 매체의 남은 용량을 분리해서 봅니다. 작은 다운로드 파일이 작은 설치 공간이나 부팅 호환성을 보장하지 않습니다. rootfs 여유 변수 · Wic 배치
English
Rootfs extra space is measured in KiB. It does not allocate all remaining media space or enable automatic partition growth. Filesystem free space, Wic geometry, compressed download size and physical capacity are separate quantities.
라이선스 선언·변경 감지·이미지 목록을 나눠 읽습니다
LICENSE는 선언, LIC_FILES_CHKSUM은 지정한 원문 변화의 감지입니다. 5.0에서는 checksum 불일치가 configure 단계 검사를 실패시키므로, 값만 바꾸지 말고 변경된 원문을 검토합니다. 생성된 이미지 license manifest도 완전한 배포물 목록은 아닙니다. 빌드용 DEPENDS로만 연결한 정적 라이브러리는 manifest와 소스 묶음에서 빠질 수 있습니다. 실제 배포물과 소스 제공 범위는 별도로 확인하며, 빌드 성공을 법적 준수 판정으로 읽지 않습니다. Yocto 5.0 라이선스 추적과 한계
English
LICENSE declares; LIC_FILES_CHKSUM detects changes to selected text and can fail configuration. Review the change before updating its checksum. Image manifests and generated source archives can omit static libraries used only through build-time DEPENDS. They are evidence inputs, not a complete compliance conclusion.
기능 선언과 실제 빌드 결과를 구분합니다
Yocto 5.0.13에서 MACHINE_FEATURES는 하드웨어 기능, DISTRO_FEATURES는 배포판의 지원 선택을 나타냅니다. COMBINED_FEATURES는 양쪽 조건이 필요한 선택된 기능에 쓰이며, 모든 항목을 일괄 교집합 처리한다는 뜻이 아닙니다. 기능과 패키지는 일대일이 아니고, recipe의 configure 옵션이나 PACKAGECONFIG에도 영향을 줍니다.
최종 효과는 해당 recipe와 image metadata에서 확인합니다. 배포판 기능을 켰다고 커널 설정까지 자동으로 켜진다고 가정하지 않습니다. Yocto 5.0.13 기능 정의
English
MACHINE_FEATURES describes hardware capabilities; DISTRO_FEATURES expresses distribution choices. COMBINED_FEATURES applies to selected features needing both, not every entry in the lists. Features are not one-to-one with packages and can affect recipe configuration or PACKAGECONFIG. Check the consuming recipe and image metadata. A distro feature does not automatically enable required kernel configuration.
패키지 파일과 패키지 저장소는 서명 대상이 다릅니다
Yocto 5.0.13 문서는 RPM 패키지 서명에 sign_rpm, RPM·IPK 피드 서명에 sign_package_feed를 설명합니다. 개별 파일과 저장소 metadata의 검증은 구분해야 합니다. 예전 글의 sign_ipk 예만으로 이 버전의 개별 IPK 서명 절차가 성립한다고 판단하지 않습니다.
정확한 릴리스·패키지 형식·대상 장비의 검증 설정을 확인하며, 키나 암호 문구를 공개 예제에 넣지 않습니다. 여기서는 패키지를 생성·서명하거나 피드를 배포하지 않았습니다. Yocto 5.0.13 패키지와 피드 서명
English
The 5.0.13 guide documents sign_rpm for RPM packages and sign_package_feed for RPM/IPK feeds. These protect different artifacts. An old sign_ipk example does not establish individual-IPK signing for this release. Verify the release, backend and target verification policy; keep keys and passphrases out of public examples. No package signing or feed deployment was performed here.
따라 해 볼 자료: Yocto Textbook 17장
Yocto Textbook 한국어판은 QEMU ARM64 학습 workspace에서 BSP, 애플리케이션, 커널 모듈, SDK와 디버깅을 연결합니다. 영어판과 repo manifest도 공개되어 있습니다. Yocto Project 공식 매뉴얼이 아닌 제3자의 학습용 프로젝트입니다. 아래 장별 링크는 2026-10-20 검토 기준인 한국어판 937c259 버전에 고정했습니다.
- 큰 그림과 진입점: 00 빌드 파이프라인, 01 환경 진입, 02 빌드 템플릿. 기존 본문의 흐름을 확인한 뒤
envsetup.sh와 초기 설정을 살펴봅니다. - 대상과 이미지 정책: 03 BSP·Machine·Kernel, 04 Image·Packagegroup, 05 Distro·systemd. 하드웨어 선택, 제품 정책, 설치 패키지 묶음을 나누어 읽습니다.
- 외부 소스와 모듈: 06 externalsrc, 07 커널 모듈. 로컬 소스로 반복 개발하는 방식과 현재 커널에 맞춘 모듈 패키징을 비교합니다.
- 애플리케이션과 외부 패키지: 08 Makefile 레시피, 09 CMake 레시피, 10 meta-openembedded. 빌드 class,
do_install, 외부 layer 활용을 확인합니다. - 운영 기능: 11 SELinux, 12 systemd 서비스. 11장의 초기 모드는
permissive이므로 강제 접근제어가 검증된 제품 구성으로 읽지 않습니다. - 외부 개발과 변경 반영: 13 SDK, 14 devshell·커널 설정, 15 devtool. build tree 밖 개발, recipe 환경 재현, 변경의 patch·레시피 반영을 구분합니다.
- 문제 진단: 16 FAQ·디버깅. 실패한 recipe와 task에서 시작해 로그, 최종 변수값, 적용된
.bbappend, buildhistory를 확인합니다.
manifest의 Yocto 기반은 5.0 Scarthgap 브랜치입니다. 브랜치 revision이나 예제의 AUTOREV를 사용하면 시간이 지나며 가져오는 코드가 바뀔 수 있습니다. 제품용 재현 빌드에서는 프로젝트 revision과 recipe의 SRCREV를 고정하고 공식 Yocto 5.0 문서에서 명령과 layer 호환성을 확인합니다. Textbook 04장의 이미지 예시는 tar.bz2와 ext4이며, 앞 절의 Wic 디스크 배치 실습과 같지 않습니다. 이 글에서 Textbook의 전체 빌드·보드 실행을 재현한 것은 아닙니다.