Yocto IMAGE_INSTALL vs RDEPENDS — 어디에 넣나?

Yocto IMAGE_INSTALL RDEPENDS를 헷갈리면 “왜 이 패키지가 루트fs에 있는지”를 추적하기 어렵습니다. 한 줄로 나누면 이렇습니다. 이미지에 직접 올릴 목록은 IMAGE_INSTALL(또는 packagegroup를 그 목록에 넣는 방식), 어떤 패키지가 런타임에 꼭 필요한 다른 패키지는 RDEPENDS입니다. 이 글은 Yocto Project Development Tasks Manual의 Customizing Images와 Reference Manual Variables Glossary를 근거로 한 최소 howto입니다. 보드 일화·가격·제휴는 없습니다.

이미지에 넣을 때는?

한 줄 답: 루트 파일시스템에 의도적으로 포함할 패키지(또는 packagegroup) 이름은 이미지 쪽 IMAGE_INSTALL에 둡니다. 로컬 실험이면 local.conf의 IMAGE_INSTALL:append, 제품 이미지면 커스텀 이미지 recipe·packagegroup를 권장합니다.

문서 요지:

local.conf에서 추가할 때는 IMAGE_INSTALL:append = " pkg" 형태를 씁니다. :append는 선행 공백이 필요하고, +=보다 이미지 recipe/?= 순서 이슈를 피하기 쉽습니다.
특정 이미지만 바꾸려면 IMAGE_INSTALL:append:pn-core-image-minimal = " strace"처럼 pn 오버라이드를 붙입니다.
core-image-*만이면 CORE_IMAGE_EXTRA_INSTALL도 가능합니다.
복잡한 제품 이미지는 flat 나열보다 inherit packagegroup 레시피를 만들고, 그 packagegroup 패키지를 IMAGE_INSTALL에 넣는 편이 유지보수에 유리합니다(Customizing Images Using Custom Package Groups).

최소 예 (local.conf):

IMAGE_INSTALL:append = " strace"
# 특정 이미지만:
# IMAGE_INSTALL:append:pn-core-image-minimal = " strace"

커스텀 이미지 recipe 골격:

IMAGE_INSTALL = "packagegroup-core-boot my-app"
inherit core-image

포인트는 **“이 이미지의 구성원”**을 선언하는 자리라는 점입니다. 앱 A가 라이브러리 B를 반드시 필요로 한다는 사실은 여기보다 recipe의 RDEPENDS가 맞습니다.

레시피 의존은?

한 줄 답: 패키지 이름 오버라이드와 함께 쓰는 **RDEPENDS:pkg**는 런타임 하드 의존입니다. 그 패키지가 설치되면 의존 대상도 패키지 매니저/이미지 조립이 끌어옵니다. packagegroup의 “구성 목록”도 같은 변수로 적습니다.

Variables Glossary의 RDEPENDS 요지:

빌드 타임 DEPENDS와 다릅니다. DEPENDS는 sysroot·헤더·링크용 recipe 의존이고, RDEPENDS는 타깃에 같이 있어야 하는 패키지입니다.
항상 패키지 이름 오버라이드를 씁니다. 예: RDEPENDS:${PN} = "libfoo".
packagegroup에서는 PACKAGES에 만든 가상 패키지마다 RDEPENDS:${PN}-apps = "…"로 그룹 내용을 채웁니다. 그 다음 이미지에는 IMAGE_INSTALL에 packagegroup-…만 올립니다.

문서 예시와 같은 packagegroup 패턴:

DESCRIPTION = "My Custom Package Groups"
inherit packagegroup

PACKAGES = "${PN}-apps ${PN}-tools"

RDEPENDS:${PN}-apps = "\
    dropbear \
    portmap \
    psplash \
"

RDEPENDS:${PN}-tools = "\
    oprofile \
    lttng-tools \
"

RRECOMMENDS:${PN}-tools = "kernel-module-oprofile"

이미지는 예를 들어 다음만 추가합니다.

IMAGE_INSTALL:append = " packagegroup-custom-apps"

선택적(없어도 이미지 조립이 깨지지 않게 하고 싶은) 항목은 RRECOMMENDS입니다. BAD_RECOMMENDATIONS / NO_RECOMMENDATIONS로 추천만 막을 수 있고, 하드 RDEPENDS는 이 경로로 막히지 않습니다.

둘 다 넣으면 생기는 문제는?

한 줄 답: 같은 패키지를 IMAGE_INSTALL과 어떤 패키지의 RDEPENDS에 중복 선언하면 설치는 대개 되지만, 제거·제외·감사가 깨집니다. “누가 이 패키지를 이미지에 붙잡고 있는지”가 두 경로로 갈라집니다.

자주 보는 증상:

IMAGE_INSTALL에서 지웠는데도 루트fs에 남음
다른 패키지(또는 packagegroup)의 RDEPENDS가 다시 끌어옵니다. “이미지 목록만 정리하면 빠진다”는 가정이 틀립니다.
PACKAGE_EXCLUDE / BAD_RECOMMENDATIONS가 기대대로 안 먹음
Glossary는 추천(RRECOMMENDS)만 BAD_RECOMMENDATIONS로 막을 수 있다고 명시합니다. 다른 패키지가 RDEPENDS로 요구하면 빌드 시스템은 의존 오류를 피하려고 설치를 유지합니다.
정책이 흩어짐
이미지 recipe·local.conf·앱 recipe·packagegroup에 같은 이름이 섞이면, “제품 이미지에 왜 들어갔나?” 질문에 답이 여러 갈래가 됩니다. 문서가 packagegroup을 권하는 이유도 한곳(그룹)에서 RDEPENDS로 묶고, 이미지에는 그룹만 IMAGE_INSTALL하기 때문입니다.
역할 혼동
IMAGE_INSTALL에 런타임 라이브러리만 잔뜩 나열하고 앱 recipe의 RDEPENDS는 비우면, 앱을 다른 이미지/SDK/패키지 피드에만 쓸 때 의존이 이미지에만 존재하게 됩니다. 반대로 앱 RDEPENDS에 있는 것을 이미지에 또 적는 것은 대개 중복입니다(명시적 pin이 목적인 경우 제외).

실무 규칙(문서 흐름과 맞춤):

목적	어디에
이 이미지에 꼭 넣을 앱·도구·packagegroup	`IMAGE_INSTALL` (`:append` / 이미지 recipe)
패키지가 런타임에 꼭 필요한 다른 패키지	`RDEPENDS:pkg` (앱·라이브러리 recipe)
여러 이미지를 공유하는 구성 묶음	`inherit packagegroup` + `RDEPENDS` → 그 그룹만 `IMAGE_INSTALL`
있으면 좋지만 필수는 아님	`RRECOMMENDS` (+ 필요 시 `BAD_RECOMMENDATIONS`)

중복을 줄이는 순서:

앱/라이브러리 recipe에 진짜 런타임 필수만 RDEPENDS로 적습니다.
제품 단위로 묶을 내용은 packagegroup의 RDEPENDS로 모읍니다.
이미지에는 앱 패키지 또는 packagegroup 이름만 IMAGE_INSTALL에 올립니다.
“빼기”는 이미지 목록만 보지 말고 bitbake -e / buildhistory·패키지 의존 그래프로 누가 RDEPENDS로 붙잡는지를 확인합니다.

자주 묻는 질문

Q. IMAGE_INSTALL에 라이브러리를 직접 넣어도 되나?
A. 가능하지만, 그 라이브러리를 쓰는 패키지의 RDEPENDS가 비어 있으면 다른 이미지·패키지 설치 경로에서 깨질 수 있습니다. 라이브러리는 소비자 recipe의 RDEPENDS(또는 자동 shlib 의존)가 기본입니다.

Q. packagegroup 없이 IMAGE_INSTALL만 길게 써도 되나?
A. 프로토타입·local.conf 실험에는 충분합니다. 문서도 복잡한 커스텀은 packagegroup을 best approach로 적습니다.

Q. RDEPENDS와 DEPENDS를 같이 쓰나?
A. 역할이 다릅니다. 헤더/링크가 필요하면 DEPENDS, 타깃에 패키지가 같이 있어야 하면 RDEPENDS. 많은 경우 자동 런타임 의존이 생기지만, 스크립트·데이터·명시적 패키지 이름은 RDEPENDS로 적습니다.

정리

이미지 구성원은 IMAGE_INSTALL, 런타임 필수 관계는 RDEPENDS입니다. packagegroup은 후자로 묶고 전자에는 그룹만 올리는 패턴이 mega-manual의 권장 흐름입니다. 둘에 같은 패키지를 중복하면 설치보다 제거와 감사가 먼저 아픕니다. 자세한 문법은 Customizing Images와 Variables Glossary — IMAGE_INSTALL / RDEPENDS를 보시면 됩니다.

공식 문서는 어디인가?

Customizing Images
Variables Glossary (IMAGE_INSTALL, RDEPENDS, RRECOMMENDS, BAD_RECOMMENDATIONS, PACKAGE_EXCLUDE)
OE-Core 예: meta/recipes-core/packagegroups/packagegroup-base.bb