Launchpad PPA 생성.에서, PPA 를 만드는 법에 대해 정리했었다.
이 글에선, 만들어진 PPA 에 꾸러미를 올리는 법을 정리한다.
여기에 있는 모든 내용은, 아래에서 다 찾을 수 있다.
판본(Version)명을 붙이는 방법에 대해선 다음 글을 참고한다.
맨 위 글에서도 얘기했었고, 지금 다시 언급하지만, 여기에 올리는 꾸러미는 Deb 꾸러미가 아니고, Source Package 이다. 컴파일/빌드는 Launchpad 에서 알아서 해준다. 내가 할 일은 소스 파일을, 우분투(정확하게는 Debian)가 알아먹을(?) 수 있는 형태로 가공하여 꾸러미 형태로 올리는 것이다.
(이것을 몰라서 데비안 꾸러미를 올리고 왜 안될까.. 한동안 고민했었다. PPA 에 작업을 한 뒤, 뭔가 문제가 생겼다면 등록한 이메일로 오류 내용이 오니 잘 살펴볼 것.)
Deb 꾸러미는 build-essential 을 설치하고, 적절한 개발 라이브러리들을 설치한 뒤, dpkg-buildpackage 로 만들 수 있다. 이 글 참고.
Source 꾸러미는 저걸로 하는 것이 아니고, debuild 라는 다른 프로그램으로 하게 된다. 이것은 devscripts 꾸러미 안에 들어있다.
따라서, 맨 처음에 할 일은 이것을 설치하는 것이다.
sudo apt install devscripts
그 다음은.. 사실 꽤 복잡한데.. 간단하게만 정리한다.
먼저 가장 중요한 프로그램 소스 코드.
CopyQ 를 예로 들겠다. CopyQ Github 페이지에서 Source code (tar.gz)를 받고, 압축을 푼다. 현재 상황은 이렇다.
이제 소스 디렉토리(압축이 풀린)로 이동한다.
PPA 에 올리기 위해선 소스 디렉토리에 debian 이라는 디렉토리가 필요하고, 그 안에 몇가지 적절한 파일이 있어야 한다. 다음 글을 참고한다.
프로그래밍 지식이 일천하므로, 맨 땅에서 debian 파일들을 만들어내는 건 불가능하니, 다른 이들이 이미 만들어놓은 것을 참고하여 적절히 넣어주면 된다. 데비안 쪽에선 한번도 빌드 된 적이 없는 프로그램을 데비안 꾸러미로 만들 생각이라면... 그냥 포기하는 편이 낫다~ ㅎㅎ (아니면 공부를 좀 더 하든가..)
제작자에 따라서, debian 파일을 직접 제공해주기도 하고(Nimf), 없는 경우(Cantata)도 있다. CopyQ 는 PPA 가 아닌 다른 저장소를 사용하는데, Github 에서 받을 수 있는 소스에는 debian 디렉토리가 없지만, 다른 저장소로 가면 이 파일들을 구할 수 있다.
이런 식으로, 소스마다 다 다르다. debian 파일들이 제공되고 있다면 거의 건드릴 것이 없고, 없다면, (어떻게든) 구해야 한다.
........
debian/changelog
debian 디렉토리에 있는 파일 중에서, 소스 꾸러미를 만들기 위해 가장 중요한 파일은 changelog 이다. 이것을 적절히 수정해줘야 한다.
편집기를 사용해서 적당히 수정해줘도 되지만, 가끔 오류가 나는 때가 있다. 이럴 땐 dch -r -m 명령으로 문제를 바로 잡을 수 있다.
CopyQ 제작자가 배포한 debian/changelog 를 보면 이런 식으로 되어 있다.
copyq (2.7.1~xenial) xenial; urgency=low
* v2.7.1
-- Lukas Holecek <hluk@email.cz> Mon, 20 Jun 2016 12:13:00 +0900
copyq (2.7.0) stable; urgency=low
* v2.7.0
-- Lukas Holecek <hluk@email.cz> Mon, 2 May 2016 22:13:00 +0900
...... 후략
이 형식에 맞게끔 내용을 추가해주면 된다.
copyq (2.7.1~xenial) xenial; urgency=low
프로그램명과 판본을 넣어주고, 우분투 이름도 꼭 제대로 넣어줘야 한다. Nimf 같은 경우, 제작자는 xenial 부분에 stable 이라고 넣어놨는데, 이걸 그대로 소스 꾸러미로 만들면 오류가 발생한다. (제작자는 사용자가 어떤 환경에서 사용할 지 알 길이 없으므로 그냥 stable 이라고만 했을 것이다.)
판본을 붙이는 데도 규칙이 있다. 여기는 그냥 2.7.1~xenial 로만 되어 있어서 복잡할 게 없지만, 다음과 같은 경우를 보자.
hello (2.8-0ubuntu1)
프로그램 이름이 hello 이고, 현재 버전은 2.8이다. 뒤에 -0ubuntu1 이 붙었는데, 이것을 'Distro revision' 이라고 한다. 이것은, 프로그램 버전은 그대로 이고, 패키징 오류라든가 기타 이유로 뭔가 수정사항이 생겼을 때 이전 판과 구분해주기 위해서 붙인다.
Basic Overview of the debian/ Directory 에 있는 내용을 그대로 옮긴다.
Notice that the version has a -0ubuntu1 appended to it, this is the distro revision, used so that the packaging can be updated (to fix bugs for example) with new uploads within the same source release version.
Ubuntu and Debian have slightly different package versioning schemes to avoid conflicting packages with the same source version. If a Debian package has been changed in Ubuntu, it has ubuntuX (where X is the Ubuntu revision number) appended to the end of the Debian version. So if the Debian hello 2.6-1 package was changed by Ubuntu, the version string would be 2.6-1ubuntu1. If a package for the application does not exist in Debian, then the Debian revision is 0 (e.g. 2.6-0ubuntu1).
그러나.. 공식 저장소에 올릴 것이 아니라면, 그냥 적당히 붙여줘도 될 것 같다.
다만!! 반드시 기억해야 하는 것 한가지.
예를 들어, copyq (2.7.1~xenial) xenial; urgency=low 라고 된 changelog 를 사용해서 소스 꾸러미를 만들고 PPA 에 올렸는데, 빌드 시에 오류가 생겨서 오류를 수정한 뒤 다시 PPA 에 올렸다고 하자. Launchpad 에선 이것을 허용하지 않는다. 프로그램 자체 버전이 똑같더라도, changelog 에 있는 판본명은 같아선 안된다. 이럴 경우 적절히 이름을 바꿔줘야 한다.
확실하겐 모르겠지만, 보통 이런 식으로들 하는 것 같다.
copyq (2.7.1~xenial1) xenial; urgency=low
또는
copyq (2.7.1~xenial~1) xenial; urgency=low
등등.
다음으로 봐야 할 것은 Maintainer 이름과 이메일 주소다. 이게 그냥 이름과 이메일 주소가 아니라, PGP 키를 사용할 때 등록한 이름과 주소이다.
gpg --list-keys
이 명령을 실행하면 uid 항목이 있는데, 거기에 나와있는 그대로 넣어줘야 한다. 괄호까지 있다면 그것도 그대로 넣어줘야 한다.
만약, 여기 내용을 내 uid 항목과 다르게 넣어줬다면, 나중에 debuild 에서 -k 를 넣어줘야 한다. (뒤에 설명)
시간은 적절히 형식에 맞게 넣어준다.
debian/source/format
이 파일의 내용은 크게 두가지인 것 같다. (정확하게는 세가지)
3.0 (native)
3.0 (quilt)
- native 일 경우, 원본 소스 파일에 debian 디렉토리가 같이 포함되어 패키징 된다.
- quilt 일 경우, 원본 파일은 source.orig.tar.gz 형식으로 묶이고, debian 파일은 따로 압축되어 패키징 된다.
따라서 3.0 (quilt) 라면, 아까 받았던 소스 파일 이름을 바꿔줘야 한다.
정확한 파일명은, 나중에 최종 명령을 수행하면(debuild -S) orig.tar.gz 파일이 없다면서 오류가 나므로, 그때 파일명을 확인하고 소스파일 이름을 그것으로 바꿔주면 된다.
뭘로 해야할런지는 확실히는 모르겠지만.. 그냥 quilt 로 해주는 편이, 약간 번거롭긴 하지만 괜찮을 것 같다.
** native 라면, 원본 소스 압축파일은 없어도 되고, quilt 라면 원본 파일은 source.orig.tar.gz 형식으로 반드시 그림과 같은 위치에 있어야 한다.
** Quilt? 누비이불??
거기에서 온 것 같긴 한데.. 소프트웨어에서도 쓰는 단어라고 한다. 흔히 Patch 라고 부르는 것과 유사한 개념인 듯.
이 정도면 debian 디렉토리내 파일은 더 수정할 것이 없다. (물론.. 가장 어려운 control 파일이 있긴 하지만 그건 내 능력 밖이다...)
빌드에 영향을 미치는 debian 파일들은 모두 잘 작성되어있다고 가정하자.
빌드 확인; Deb 꾸러미 만들기
또 말하지만, PPA 에 올라가는 건 실행파일이 아니고 소스파일이다. 그러나, 실행파일을 미리 만들어볼 필요가 있다. 빌드가 잘 되는지 확인을 먼저 하고 올려야지, 무턱대고 올렸다가 오류가 발생하면 더 귀찮아진다.
이제 소스코드가 압축해제되어 있는 디렉토리로 이동한다. 위 그림이라면 CopyQ-2.7.1 디렉토리이다.
여기에서 다음과 같이 빌드 명령을 내린다.
dpkg-buildpackage -us -uc
-us : 소스에 PGP 서명을 하지 말 것.
-uc : .change 에 PGP 서명을 하지 말 것.
테스트로 만들어볼 것이므로 PGP 서명은 필요없다. 오류가 발생한다면... 재주껏 해결하고, 오류가 없이 끝났다면, 이제 '드디어' 소스 패키지를 만들 차례다.
소스 꾸러미 만들기
명령은 아래와 같다.
debuild -S
-S 는 소스 패키지만 만들라는 의미이다. 따라서, debuild 로 바이너리도 만들 수 있단 얘긴데.. (그냥 debuild 라고만 입력하면 된다.)
debuild = dpkg-buildpackage + lintian (build under the sanitized environment variables) 라고 한다.
만약 debuild 로 해서, deb 꾸러미까지 같이 만들면, dput 으로 올릴 때 소스가 아닌 꾸러미가 올라가기 때문에 PPA 에서 오류가 발생한다.
debuild -S -k0x12345678
changelog 파일에 PGP uid 를 적절히 넣지 않았을 경우, -k 뒤에 PGP 키를 넣어줌으로써 PGP 사인을 할 수 있다. PGP 키는 OpenPGP 를 등록할 때 사용한 이메일주소다.
(만약, 다른 이의 PPA 에 올라있는 소스를 내려받아 그대로 내 PPA 에 올릴 때, 이런 식으로 서명하여 소스 꾸러미를 만들면 되겠다.)
그러나.. 이것보단 changelog 에 넣어주는 편이 좋을 것 같다.
소스 꾸러미 올리기
드디어!
업로드는 간단하다.
dput ppa:your-lp-id/ppa <source.changes>
ppa:your-lp-id/ppa 는 내 PPA 주소를 말함이고, <source.changes> 는 debuild 로 생성된 .changes 파일이다.
이렇게 명령을 내리면, 알아서 PPA 로 올라가고, 소스 자체에 문제가 없다면 빌드 작업이 시작된 뒤, 조금 기다리면 Publish 가 되어, PPA 에서 프로그램을 내려받을 수 있게 된다.
참고로, 뭔가 문제가 있을 경우, PPA 에 등록된 이메일로 설명이 보내진다. 내용을 잘 읽어보고 조치를 취하면 된다.
문제가 된 소스 꾸러미는 PPA 에서 지울 수가 있다.
이후, 새롭게 제작한 소스 꾸러미를 올려야 하는데, 위에도 언급했지만, 버전이 동일하면 dput 후에 오류가 발생한다.
따라서, 일단 PPA 에 올린 후 수정이 가해졌다면, 판번호는 반드시 이전 것과 달라져야만 한다.
실제 판번호가 달라져야 하는 것은 아니고, changelog 에 있는 판번호를 적절히 바꿔주면 된다.
예를 들어, 2.7.1~xenial 이 오류가 발생했다면, 2.7.1~xenial-1 정도로 바꿔주면 된다.
아아아아!!!
큰 숙제 했네..
참고한 문서들은 다음과 같다.
'소프트웨어 > 웹 서버 등 개발 환경 세팅' 카테고리의 다른 글
| 51. VPS 서버 세팅 (0) | 2022.09.06 |
|---|---|
| 50. 인증 (0) | 2022.08.30 |
| 48. How to write Shell Script in Linux (0) | 2022.08.24 |
| 47. Rufus, Etcher 대체용 Ventoy 멀티 OS (0) | 2022.08.24 |
| 46. 리눅스용 런처 만들기 (0) | 2022.08.23 |