이 문서는 데비안 패키지를 제작하는 과정을 일부 다루지만, 대체로 이미 존재하는 패키지를 다시 패키징하는 방법을 다룰 것입니다. 물론 새로운 프로그램을 패키징할 필요도 있지만, 과거에 비해 아주 특별한 프로그램이 아니면 대체로 데비안-계열의 패키징과 관련된 파일을 얻을 수 있기 때문입니다.
어쨌든, 패키징을 하기 전에 DontBreakDebian을 읽고, 결과로서, 가능한 데비안 저장소의 패키지를 이용하는 것이 바람직해 보입니다.
한편, 데비안은 안정(stable), 테스팅(testing), 불안정(unstable), 실험(experimental)의 저장소가 존재합니다. 이들 저장소에서, 웹에서 패키지를 찾아서, 소스를 가져올 수도 있지만, 변조가 발생했는지 확인하는 것이 귀찮습니다.
따라서, 데비안의 모든 소스 저장소를 읽고, 필요에 따라 적절한 저장소에서 패키지 소스를 다운로드할 수 있습니다. 게다가, 패키지 저장소에 있는 버전들을 확인할 필요가 있습니다:
먼저, /etc/apt/sources.list에 다음을 추가합니다.
deb http://ftp.kaist.ac.kr/debian/ bullseye main contrib non-free
deb http://ftp.kaist.ac.kr/debian/ testing main contrib non-free
deb http://ftp.kaist.ac.kr/debian/ unstable main contrib non-free
deb http://ftp.kaist.ac.kr/debian/ experimental main contrib non-free
deb-src http://ftp.kaist.ac.kr/debian/ bullseye main contrib non-free
deb-src http://ftp.kaist.ac.kr/debian/ testing main contrib non-free
deb-src http://ftp.kaist.ac.kr/debian/ unstable main contrib non-free
deb-src http://ftp.kaist.ac.kr/debian/ experimental main contrib non-free
만약 같은 이름의 소스 패키지가 존재하면, 기본적으로 가장 높은 버전이 다운로드되고, 필요에 따라 저장소의 이름을 붙여서 다운로드받을 수 있습니다.
- apt source redis
실험 버전이 존재해서 해당 버전이 다운로드됩니다:
- apt source redis/stable
안정판 bullseye 소스 패키지가 다운로드됩니다.
| 경고! 경고! 경고! 바이너리는 결코 안정판 외에는 설치하지 마십시오!! 위와 같이 설정하면, 거의 모든 패키지들이 불안정판으로 설치될 것입니다. 아래 설정을 반드시 추가하십시오!! |
근본적으로 안정판 외에 다른 저장소의 바이너리 패키지를 설치하지 못하도록 설정하셔야 합니다. 예를 들어, /etc/apt/preferences.d/all_debian_repo 파일에 다음을 입력하십시오:
Package: *
Pin: release a=testing
Pin-Priority: -10
Package: *
Pin: release a=unstable
Pin-Priority: -10
Package: *
Pin: release a=experimental
Pin-Priority: -10
Personal backport packaging
주로 시드 버전에서 소스를 가져와서 다시 패키징을 시도하겠지만, 패키지 의존성으로 인해 바로 패키징이 안될 수 있습니다. 예를 들어, pipewire 프로그램을 빌드하기 위해, 다음 과정을 시도합니다:
- apt source pipewire/unstable
- cd pipewire-Tab ↹
- sudo apt build-dep pipewire
- time dpkg-buildpackage -i -us -uc -b
아마도 libfreeaptx, libxfixes, xorgproto 프로그램의 버전 업그레이드가 필요할 것입니다. 이 세 파일에 대해 위와 같은 과정을 반복하고, 빌드된 패키징을 설치한 후에 pipewire 빌드가 가능할 것입니다.
게다가, libdrm와 같은 프로그램은 시드 버전을 설치하면, 다른 프로그램을 빌드하기 위해 빌드 의존성 프로그램을 설치하려고 시도해도 버전이 맞지 않아서 설치가 되지 않을 수 있습니다. 이때, 개별적으로 해당 프로그램들을 설치하고, 그래도 빌드가 되지 않으면, 의존성 패키지를 먼저 빌드해야 합니다.
어쨌든, 처음에는 의존성이 거의 없는 프로그램을 빌드해 보는 것이 좋겠습니다.
데비안 패키지 다운그레이드
시드 등의 패키지로 업그레이드를 한 후에, 필요에 따라, 예를 들어, 다른 패키지를 컴파일하기 위해, 다운그레이드가 필요할 수 있습니다.
이 과정은 의존성으로 인해 심각한 상황을 초래할 수 있기 때문에, 적절한 처리가 필요합니다. 예를 들어, 앞의 예제, libdrm을 시드 버전 백포트를 설치한 후에, 다시 안정판으로 되돌리기 위해, 먼저, 시스템에 설치된 해당 프로그램의 패키지들을 알아냅니다:
- dpkg -l | grep libdrm
여기서 설치된 버전을 알 수 있습니다. 이제, 알아낸 버전으로 다시 설치된 프로그램을 검색합니다.
- dpkg -l | grep 2.4.114-1
위의 두 정보로부터 libdrm과 관련된 시스템에 설치된 모든 패키지를 알아낼 수 있습니다. 그런-다음, 안정판의 버전을 설치해야 합니다
- 데비안 패키지 검색 : 과거에는 여기서 일일이 하나씩 찾아서 다운로드해서 덮어쓰기를 진행했습니다. 또는
- sudo apt install libdrm-amdgpu1/bullseye libdrm-common/bullseye libdrm-dev/bullseye ... : 이런 식으로 모든 패키지를 한꺼번에 다운그레이드할 수 있습니다.
주로 두 번째 방법이 덜 시간-소모적이지만, 잘못 사용할 경우에 시스템을 크게 훼손할 수 있습니다. 반드시 시스템에 설치된 모든 패키지를 한꺼번에 다운그레이드해야 합니다. 일부를 다운그레이드하려고 시도하면, 남은 패키지를 지우고 그것과 의존성에 걸려있는 모든 패키지를 지우려고 시도할 것입니다.
따라서, 두 번째 방법을 이용하지만, 나오는 메시지를 주의해서 읽고 대처하시기 바랍니다. 무작정 Enter를 누르는 습관을 버리시기 바랍니다!
몇 가지 고려사항
다음 사항을 고려해 보십시오:
GCC 컴파일러는 여러 버전을 설치할 수 있지만, 특별한 경우가 아니라면, 현재 배포판에서 제공하는 10 버전 외에 다른 컴파일러는 설치하지 않는 것이 좋겠습니다. 배포할 때, 의존성으로 인해 컴파일러와 관련된 파일을 함께 배포해야 하기 때문입니다.
DEB_BUILD_OPTIONS – 대부분의 패키지 관리자는 데비안의 정책에 따라 패키지를 만들겠지만, 일반 사용자는, 기존의 패키지를, 간단히 수정, 간단한 패치 등을 추가해서 사용하는 경우가 많으므로, 불필요한 디스크 사용, 또는 빌드 소모 시간을 줄이기 위해 적절히 타협할 수 있습니다. 적당한 파일, .bashrc 등에 별칭을 만들어 둘 수 있습니다:
- alias dpkg-buildpackage='DEB_BUILD_OPTIONS="nodocs notest nocheck noddebs" dpkg-buildpackage'
- nodocs는 일부 rustc로 작성된 프로그램에서 문제가 발생할 수 있으므로, 선택적으로 적용할 수 있습니다.
- notest, nocheck는 특정 패키지에서 test, check 중에 internal 오류가 발생할 때, 적용해야 패키지를 만들 수 있습니다.
- noddebs는 dbgsym 파일을 만들지 않기 위해 적용할 수 있습니다.
CFLAGS 등을 설정해서 컴파일을 할 수 있지만, 특정 옵션은 많은 패키지에서 예상되지 않는 오류를 발생할 수 있고, 더구나, 패키지들은 패키지 관리자에 의해 특정 CFLAGS 등을 별도로 구성하기 때문에, 굳이 사용할 필요는 없을 것으로 보입니다. 완전한 지식이 없으면, 사용하지 마시기 바랍니다!!
그 외 알아야 할 사항
- meson 패키지는 bullseye에 있는 패키지들은 bullseye의 버전을 사용하고, 더 높은 버전은 bullseye-backports를 이용할 수 있습니다. 일부 안정판 패키지, 예를 들어, nautilus는 높은 버전의 meson으로 컴파일할 경우에 이상한 오류를 만날 수 있습니다.
- 우분투 패키지 빌드 도구를 사용해서는 안됩니다!! 우분투에 대한 소스 패키지를 사용할 수는 있지만, 그런 패키지에서 오류가 발생한다고 해서 우분투의 패키지 빌드 도구, 예를 들어, 우분투 dpkg를 데비안에서 빌드해서 사용해서는 안됩니다. 빌드되는 패키지도 있지만, 빌드되지 않는 패키지들도 있기 때문에, 그냥 소스 패키지의 오류를 수정하는 것이 더 안정적입니다.
Backport packaging example
먼저 패키징에 필요한 프로그램들을 다음과 같이 설치할 수 있습니다. 소스 패키지와 다르게 바이너리 패키지는 가능한 안정판만 사용하십시오!
- sudo apt install build-essential devscripts debhelper
예제로, 의존성이 없는 redis 패키지를 백포트로 패키징해 보겠습니다. 위와 같이 소스 패키지 저장소 구성이 되어 있으면, 가장 최근의 소스 패키지를 가져오기 위해,
- apt source redis
- cd redis-Tab ↹
몇 가지 정보를 확인하기 위해,
- head debian/changelog
이제, 버전 정보와 urgency 정보로부터
- dch -v 5:7.0.0-1 -D bullseye -u medium
아마도, 경고 메시지가 나올 수 있는데, 패키징에 필요한 이메일주소(DEBEMAIL)과 이름(NAME)을 지정하기 않았기 때문입니다. 이것을 지정하지 않으면, 시스템의 호스트이름과 사용자 id로부터 정보를 얻어서 기입하는데, 대체로 도메인을 가지고 있지 않으면, 잘못된 값을 입력할 것입니다.
따라서, ~/.bashrc 파일 등에 다음 내용을 추가해 줍니다.
export DEBEMAIL="전자우편 주소"
export EMAIL="전자우편 주소" # 커널 패키지에서 필요
export NAME="자신의 이름"
이때, 이름은 굳이 본명을 사용하지 않아도 상관없지만, 대신에 배포를 고려하시면 일관성을 유지하는 것이 좋겠습니다.
- source ~/.bashrc
이제 새롭게 명령을 실행하면 직전에 설정한 값으로 변경되어 입력이 될 것입니다:
- dch -v 5:7.0.0-1 -D bullseye -u medium
다음으로, 변경한 내용을 입력해야 하는데, 패치를 삽입 등의 내용이 없으면, 다음 정도로 입력할 수 있습니다:
- Rebuild for bullseye.
이제 패키지를 만듭니다:
- time dpkg-buildpackage -us -uc -b
시스템마다 다르지만, 시간이 꽤 지난 후에, 예를 들어 24분 정도가 걸릴 수 있습니다.
이 경우에서 메시지 출력을 보면, 대부분 test에 쓰임을 알 수 있습니다. 빌드 시간을 줄이기 위해,
- time DEB_BUILD_OPTIONS="nodocs notest nocheck" dpkg-buildpackage -i -us -uc -b
아마도, 수십 초, 예를 들어 13초 정도에 패키징이 될 수 있습니다.
Source package building
패치 등을 포함해서, 소스 패키지에 변경이 발생하면, 소스 패키지를 배포하는 것이 좋습니다. 왜냐하면, 패치를 확인하고 싶은 사용자도 있을 수 있기 때문입니다.
그러기 위해, 먼저 키를 생성하고, 그런-다음 아래와 같이 서명할 수 있습니다:
- time dpkg-buildpackage -i -S --sign-key=key_id -uc
이제, 새롭게 만들어진 dsc 파일을 보시면, 자신의 키로 서명이 되어 있음을 알 수 있습니다.
Rebuild from Other repositoy sources
데비안 저장소가 아닌 저장소, 특히 우분투 저장소와 우분투에 대한 PPA에서 가져온 소스 패키지를 다시 빌드하는 경우를 생각해 보십시오.
예를 들어, 우분투 yaru 테마는 아이콘 테마를 사용할 예정이라서, 가능한 최신 소스 패키지를 사용할 것입니다. 웹 브라우저에서 yaru theme ubuntu ppa 정도로 검색하셔서, 저장소로부터 jammy 22.04-4 버전을 눌러서, yaru-theme_22.04.4.tar.xz를 받습니다. 보통은 현재 라이브러리와 가장 비슷한 우분투 20.04 focal 소스 패키지를 사용하는 것이 좋습니다.
그런-다음 변조에 대한 우려가 되면, SHA-256 체크썸을 확인할 수 있습니다:
- sha256sum yaru-theme_22.04.4.tar.xz
게시된 값에 의심이 드시면, 해당 페이지의 dsc 파일을 읽고, 그곳에 있는 체크썸 값을 확인하십시오. 보통 서명을 남긴 파일에 있는 값은 자동으로 계산되어서 변조하기 쉽지 않습니다.
어쨌든, 이제 패키지를 풀고 패키징을 시도하면, 의존성 패키지들로 인해 패키징이 되지 않을 것입니다:
- dh-migrations, meson (>= 0.59)
먼저, dh-migrations은 우분투에서 새롭게 만들어진 패키지이고, 데비안 시스템에 설치하는 것은 좋지 않을 수 있습니다. 대신에 rules 파일에서 --with migrations를 없애고, control 파일에서 해당 의존성을 제거할 수 있습니다.
다음으로, meson은 bullseys-backports에서 설치할 수 있습니다. /etc/apt/sources.list 파일에 다음 줄을 추가합니다:
- deb http://mirror.server/debian/ bullseye-backports main
- sudo apt update
이렇게 하더라도, 기본적으로 우선 순위가 낮아서 backports에서 패키지를 설치하지 않기 때문에, 아래와 같이 명시적으로 지정해서 설치할 수 있습니다:
- sudo apt install -t bullseye-backports meson
또는
- sudo apt install meson/bullseye-backports
다른 이유로도 패키징이 되지 않을 수 있는데, 오류 메시지를 검색하셔서 적절히 대처하시기 바랍니다.
Troubleshootings
symbols 간혹, 시드 소스를 사용해서 패키지를 시도하면, symbols 파일이 맞지 않아서 패키징을 완료하지 못합니다. 이때, debian:UsingSymbolsFiles의 정보에 따라 symbols 파일을 생성할 수 있습니다. 예를 들어, libcamara 패키징에서,
- cd debian
- dpkg-gensymbols -v0.0.2 -plibcamera0 -Plibcamera0 -Olibcamera0.symbols
quilt 갑자기 nginx 패키지가 빌드되지 않는 문제가 발생했습니다. 문제를 확인하는 것이 쉽지 않았는데, 어쨌든, 모듈 패치를 적용하지 못하는 점을 발견했습니다. 결국 ~/.quiltrc 파일이 만들어져 있었고, 이 파일을 제거하고 컴파일이 됩니다. 이 파일은 수동으로 만들었는지 자동으로 만들었는지 확인하지 못했습니다. resume package building 어떤 이유에서든지 패키지를 제작 중에 중지된 빌드를 이어서 빌드하길 원할 수 있습니다. 다음과 같이 시험해 보십시오:
- time dpkg-buildpackage -i -us -uc -b
- Ctrl+c
- time dpkg-buildpackage -i -us -uc -b -nc
dpkg-1.20.11 이전 버전과 다르게, 1.20.11-1의 형식으로 버전을 올리는 것은 소스 패키지 제작에서 다음 오류가 발생합니다:
dpkg-source: error: can't build with source format '3.0 (native)': native package version may not have a revision
dpkg-buildpackage: error: dpkg-source -i -b . subprocess returned exit status 255
따라서 버전을 1.20.11.1과 같이 만들어서 오류를 피할 수 있습니다. 다른 패키지를 만들 때에도 debian/source/format을 3.0 (native)로 두셔야 소스 패키지가 만들어질 가능성이 높습니다.