우분투 사용하시는 많은 분들이 snap 에 대해 다들 아실거에요.

사실 저는 snap 이 왜 나왔는지, 그게 왜 필요한지 이해를 못하는 사람입니다.

아마도 appimage, flatpak 도 마찬가지일 것 같은데 appimage, flatpak 를 사용해 본 적이 없어서 뭐라 말하기 어렵네요.

snap 으로 어플을 설치하면 snap 패키지 버그로 인하여 네이티브로 설치해서 사용할 때는 없는 버그가 갑툭튀하는 건 기본이고요.

보안성이 좋느냐. 그것도 아닙니다. snap 어플은 호스트의 주요 자원에 접근할 수 있습니다. interface 가 있습니다.

어설프게 막아 놓아서 입력기 사용할 때 많은 불편이 따르고, gtk 는 ibus, fcitx 등의 입력 모듈을 포함하여 패키지를 해서 배포하고 있죠.

그러니 gtk 에서 패키지한 입력 모듈만 지원해주니 그외 다른 입력기들은 사용 못하는 것은 뻔하고요.

그렇다면 snap 말고 다양한 환경에서 작동하는 패키지를 만드는 방법은 없는가?

이미 있습니다.


1. 정적(static) 링킹


c 어플보면 static 링킹하는 방법으로 의존성 문제를 피할 수 있는 방법이 있습니다. 정적(static) 링킹을 하면 바이너리가 엄청 커집니다. (예; 텔레그램 공식 다운로드)


2. LD_LIBRARY_PATH 지정하는 방법


LD_LIBRARY_PATH 라고 있습니다. 사용할 동적 라이브러리의 경로를 지정해 주는 방법이 있습니다.

패키지를 제작할 때, 라이브러리 버전에 구애받지 않고 여러 리눅스에서 사용 가능하게 하려면 동적 링킹하되 LD_LIBRARY_PATH 를 지정하여 동적 링킹된 라이브러리도 함께 배포하는 방법이 있습니다.


이런 기술이 이미 있음에도 불구하고 snap 이라는 뻘짓을 하는 거죠. snap 으로 패키지를 제작하면 설치해야할 바이너리 크기가 줄어드는 것도 아닙니다. 오히려 바이너리 크기가 커집니다. 위에 말씀 드린 1,2번의 방법은 기존의 pacman, deb, rpm 으로도 다양한 리눅스 배포판에서 작동될 수 있는 통합 패키지를 제작하는게 가능합니다. pacman, deb, rpm 에서 라이브러리 버전 비종속적인 편의 기능을 지원해주는 것이 아니라 패키지 제작자가 1번으로 패키지를 생산하거나, 또는 2의 방법으로 설정을 할 수 있도록 스크립트를 같이 패키지 내에 함께 배포하면 되거든요.


그래서 저는 snap 을 구라 기술이라고 판단합니다. 유사 기술로 appimage, flatpak 라는게 있는데 직접 사용한 바 없으므로 생략하겠습니다.