Flatpak의 용도와 사용법

Linux에서 어플을 설치하는 방법은 여러가지가 있으나, 그중에서도 Flatpak에 대해 알아보겠다.

모든 내용은 Flatpak 공식 문서에서 참고하였다.

https://docs.flatpak.org/en/latest

1. Flatpak이란

Flatpak은 서로 다른 Linux 배포판 간에 어플을 배포할 수 있는 프레임워크이다.

Flatpak은 현재 리눅스 패키징 프로그램의 한계를 극복하기 위해 등장했다. 현재의 문제점은, 각각의 리눅스 배포판은 각각의 패키지 매니저와 포맷을 가지고 있어 상호 호환이 되지 않는다는 것이다. 이는 곧 파편화로 이어지고, 개발자들은 모든 배포판의 포맷을 적용해 어플을 만들거나 일부 배포판에서만 적용되게 하는 방법을 취할 수밖에 없다.

2. Flatpak의 장점

Flatpak은 다음과 같은 장점을 가진다.

Universality (범용성) : 어떤 리눅스 배포판에도 사용 가능하다. GNU 기반이 아니거나, systemd가 없거나, immutable한 배포판에서도 동작한다.
Stability (안정성) : 독립된 환경에서 실행되기에 어플이 깨져도 시스템 전체에 영향을 주지 않는다.
Rootless install : 어플이나 런타임을 설치할 때 관리자 권한을 요구하지 않는다.
Sandboxed application : 독립된 환경에서 작동해 보안에 좋다. 어플끼리 서로 격리되고, 호스트 시스템에 대한 접근도 제한된다.
탈중앙화된 배포 : 개발자나 다운스트림이 직접 자신만의 저장소를 운영하며 어플을 배포할 수 있다.
저장공간 효율성 : 여러 어플이 공유하는 라이브러리·런타임을 중복 없이 한 번만 저장한다.
델타 업데이트 : 업데이트 시 바뀐 부분만 다운로드해서 네트워크 대역폭을 아낀다.

3. Flatpak이 맞지 않는 경우

다음과 같은 상황에는 Flatpak이 맞지 않는다.

sudo, su, pkexec 등으로 권한 상승이 필요한 어플의 경우. Flatpak은 샌드박스 안에서 SUID 바이너리를 실행할 수 없다.
호스트의 /proc에 접근하거나, 다른 프로세스에 대한 무제한 접근이 필요한 경우. Flatpak은 샌드박스마다 별도의 private proc을 가지기 때문에 막혀 있다.
Flatpak의 seccomp 필터에 의해 차단된 시스템 콜을 사용하는 경우. 예를 들어 샌드박스 안에서 서브 네임스페이스를 새로 만드는 동작은 허용되지 않는다.
커널 모듈이나 드라이버. 이런 것들은 애초에 어플리케이션 단위 패키지가 아니라서 Flatpak으로 만들 수 없다.

즉, 샌드박스 형식이 어플의 작동 방식과 근본적으로 맞지 않거나, 샌드박스로 인해 핵심 기능이 너무 불편해지는 경우라면 Flatpak이 적절한 선택이 아닐 수 있다.

4. Flatpak의 기초 개념

Runtimes

런타임은 어플이 실행되기 위해 필요한 공통 라이브러리와 환경으로, 기본적인 의존성을 제공한다. 모든 어플은 런타임에 의존하여 만들어져야 하고, 이 런타임이 호스트 시스템에 설치되어 있어야 어플을 실행할 수 있다. Flatpak은 어플 설치 시 필요한 런타임을 자동으로 설치해준다.

각각의 어플은 서로 다른 런타임을 요구할 수 있고, 다른 버전의 런타임을 포함해 여러 런타임이 동시에 설치될 수 있다.

런타임은 배포판의 종류나 버전에 관계없이 동작하기 때문에 안정적이고 배포판 간 호환이 된다. 즉, OS 업데이트가 이루어지더라도 런타임 기반의 어플은 영향을 받지 않는다.

Bundled Libraries

어플이 런타임에 포함되지 않은 의존성을 요구하는 경우, 해당 라이브러리를 어플 자체에 번들로 포함시킬 수 있다. 이를 통해 개발자는 런타임이 제공하는 의존성에만 국한되지 않고 더 넓은 선택지를 가질 수 있다.

구체적으로는 다음과 같은 경우에 활용된다.

런타임에 포함되지 않은 라이브러리를 사용해야 할 때
런타임이 제공하는 것과 다른 버전의 라이브러리가 필요할 때
수정된(patched) 버전의 라이브러리를 사용해야 할 때

Sandboxes

Flatpak에서는 각각의 어플이 독립적인 환경인 샌드박스 안에서 실행된다. 샌드박스는 어플과 런타임을 포함하며, 기본적으로 어플은 샌드박스 내의 자료에만 접근할 수 있다. 유저의 파일, 네트워크, 그래픽 소켓, 버스의 서브시스템, 디바이스 등에 접근하기 위해서는 명시적으로 권한을 부여받아야 한다. 다른 프로세스에 대한 접근은 원천적으로 불가능하다.

다만, 어플의 데스크탑 파일이나 아이콘처럼 호스트 시스템에서 보여야 하는 일부 자원은 샌드박스 외부로 export된다. 예를 들어 어플 실행을 위한 데스크탑 바로가기가 여기에 해당한다.

Portals

Portal은 샌드박스 안의 어플이 호스트 환경과 상호작용할 수 있는 통로다. 샌드박스 안의 어플은 기본적으로 호스트의 파일에 접근할 수 없는데, portal을 통하면 추가적인 샌드박스 권한 없이도 필요한 데이터나 파일, 서비스에 안전하게 접근할 수 있다.

예를 들어 파일 열기 대화상자나 인쇄 기능이 portal을 통해 작동한다. 인터페이스 툴킷(interface toolkit) 중에는 portal을 transparent하게 지원하는 것도 있어, 사용자가 portal의 존재를 인식하지 못한 채 자연스럽게 사용하는 경우도 있다.

Repositories

Repository는 Flatpak 어플과 런타임이 저장되는 저장소로, Git 저장소와 매우 유사하게 동작한다. 하나의 repository에 여러 어플이 담길 수 있고, 각 어플은 버전별로 관리되어 업그레이드와 다운그레이드가 모두 가능하다.

각각의 저장소를 내 시스템에 등록한 것을 remote라고 부른다. 시스템에 여러 remote를 동시에 등록해둘 수 있고, 등록된 remote의 콘텐츠는 검색·설치·업데이트의 대상이 된다.

업데이트 시에는 Git과 마찬가지로 변경된 부분만 다운로드한다. 버전 간 동일한 부분은 다시 내려받지 않기 때문에 네트워크 사용이 효율적이다.

5. Command

flatpak command

flatpak은 Flatpak의 기본 명령어로, 뒤에 세부 명령어를 붙여서 사용한다. 예를 들어 설치는 flatpak install, 삭제는 flatpak uninstall과 같은 방식이다.

Identifiers

Flatpak은 각 어플과 런타임을 세 파트로 구성된 고유 ID로 구분한다. 예를 들어 com.memoralore.App과 같은 형태인데, 마지막 파트인 App이 object의 이름이고, 앞의 com.memoralore는 개발자를 의미한다. 같은 개발자가 여러 어플을 만들 경우 com.memoralore.App1, com.memoralore.App2와 같이 구분된다.

Identifier Triples

기본적으로는 ID만 입력해도 설치가 가능하지만, 특정 버전(예: stable)이나 특정 아키텍처(예: arm CPU)를 지정해야 하는 경우에는 identifier triple을 사용한다. 형태는 name/architecture/branch이다.

예를 들어 com.memoralore.App/aarch64/stable과 같이 입력한다. architecture나 branch 중 하나만 지정하고 싶다면 해당 파트를 비워두면 된다.

com.memoralore.App//stable    # branch만 지정
com.memoralore.App/aarch64//  # architecture만 지정

이런 지정이 필요한 경우, Flatpak CLI가 자동으로 피드백을 준다.

System versus User

Flatpak 명령어는 system-wide 또는 per-user 방식으로 실행할 수 있다.

System-wide로 설치하면 해당 시스템의 모든 유저가 어플과 repository에 접근할 수 있다. Per-user로 설치하면 설치한 유저에게만 적용된다. 기본적으로는 system-wide로 작동하며, per-user로 실행하려면 --user 옵션을 추가하면 된다.

flatpak install --user flathub org.gimp.GIMP

Basic Commands

Remote 관리

등록된 remote 목록을 확인한다.

flatpak remotes

Remote를 추가한다. flathub는 이 remote에 붙여줄 이름이고, URL은 repository의 .flatpakrepo 파일 주소다. --if-not-exists는 이미 등록되어 있는 경우 오류 없이 넘어가도록 하는 옵션이다. 이렇게 등록해두면 이후 어플 설치 시 URL을 다시 입력할 필요가 없다.

flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo

Remote를 제거한다.

flatpak remote-delete flathub

검색

등록된 remote에서 어플을 검색한다. application ID와 해당 어플이 포함된 remote 이름을 반환한다.

flatpak search gimp

설치

Remote를 등록해두었다면 remote 이름과 application ID만으로 설치할 수 있다.

flatpak install flathub org.gimp.GIMP

Remote를 등록하지 않은 경우에는 .flatpakref 파일의 URL을 직접 입력해 설치할 수 있다. .flatpakref는 어플 설명서 역할을 하는 파일로, remote 주소 정보가 담겨 있어 Flatpak이 자동으로 remote를 찾아 설치한다. 이때 remote 이름은 파일 내부에 이미 지정되어 있어 별도로 이름을 붙이지 않아도 된다.

flatpak install https://dl.flathub.org/repo/appstream/org.gimp.GIMP.flatpakref

로컬에 .flatpakref 파일을 다운받아 두었다면 파일 경로를 직접 입력해도 된다.

flatpak install org.gimp.GIMP.flatpakref

검색과 설치를 한 번에 진행할 수도 있다.

flatpak install gimp

실행 / 업데이트 / 목록 / 삭제

어플을 실행한다.

flatpak run org.gimp.GIMP

설치된 모든 어플과 런타임을 업데이트한다.

flatpak update

설치된 어플과 런타임 목록을 확인한다. --app 옵션을 붙이면 어플만 표시된다.

flatpak list
flatpak list --app

어플을 삭제한다. --unused 옵션을 사용하면 설치된 어플이 사용하지 않는 런타임과 extension을 정리할 수 있다.

flatpak uninstall org.gimp.GIMP
flatpak uninstall --unused

문제 해결

의존성 불일치 등 설치 상태의 불일치를 수정한다.

flatpak repair

어플의 portal 허가사항을 초기화한다.

flatpak permission-reset org.gimp.GIMP

Flatpak 설치 이력을 확인한다.

flatpak history

flatpak을 사용하기 위한 기본적인 내용들은 모두 다루었다. 이정도 알고 있으면 flatpak 사용에 있어 아무런 문제가 없을 것이다.

각각의 항목의 경우 좀 더 자세한 이야기들이 있는데, 이는 다른 글에서 추가로 얘기해보려 한다.