아치 리눅스에서 패키지 만들기 (AUR 포함)

• PKGBUILD
• PKGBUILD / ETC 구하기
• PKGBUILD / ETC 업그레이드
• 컴파일
• 로컬 리포지토리
• 빠른 컴파일
• PGP 서명 오류
• AUR 개발 패키지
• 오래된 패키지

Arch Linux에서 공식 저장소는 핵심, 추가 및 커뮤니티입니다. 이러한 패키지는 이미 컴파일되어 있으며를 통해 설치됩니다 pacman. 대부분의 경우 일반 사용자는이 3 개의 공식 리포지토리가 분리되어 있다는 것을 무시할 수 있습니다. 코어에는 커널, 부팅 프로세스, 네트워킹, 패키지 관리, openssh 등과 같은 가장 중요한 패키지가 포함되어 있습니다. 또한 새 버전이 출시되기 전에보다 철저한 테스트 요구 사항이 더 엄격합니다. Extra에는 X 서버, 창 관리자 또는 웹 브라우저와 같이 중요하지 않은 다른 인기있는 패키지가 포함되어 있습니다. 커뮤니티에는 덜 인기있는 패키지가 포함되어 있습니다. 트러스트 된 사용자 (다른 트러스트 된 사용자가 투표 한 약 60 명의 활성 사용자)만이 공식 리포지토리를 변경할 수 있습니다.

2019 년 공식 저장소에는 https://www.archlinux.org/packages 에 약 11,000 개의 패키지가 있습니다 . 그러나 Linux에는 다른 많은 프로그램이 있습니다. 따라서 AUR (Arch Linux User Repository)이 존재하므로 모든 Arch 사용자는 새 프로그램을 추가하고 유지 관리자가되거나 현재 유지 관리자없이 "분리 된"패키지를 채택 할 수 있습니다. AUR에는 https://aur.archlinux.org/ 에 약 55,000 개의 패키지가 있습니다 .

AUR과 3 가지 중요한 차이점이 있습니다.

1. 다시 말하지만,이 패키지는 모든 사용자, 심지어 새로운 패키지로 제작할 수 있습니다.
2. AUR PKGBUILD에는 컴파일 된 바이너리가 아닌 패키지를 자동으로 만드는 쉘 스크립트 만 있습니다 . (때로는 작은 텍스트 패치 또는 설치 / 업그레이드 / 설치 제거 셸 스크립트도 포함되어 있습니다). 이로 인해 사용자가 악성 코드를 배포 할 수있는 기회를 줄이면서 모든 사용자가 기여할 수있는 엄청난 작업을 수행했습니다. 아치 커뮤니티는 여전히 AUR 패키지 문제와 관련하여 여전히 도움이되지만, 그 사용은 귀하의 책임입니다. 그것이 제공하는 것은 모두이므로 PKGBUILD궁극적으로 귀하 PKGBUILD가 사용할 것을 검토하는 것은 귀하의 책임 입니다. (많은 사용자는이 작업을 수행하지 않고 다른 사용자에게만 의존하여 감시합니다.)
3. 때문에 pacmanAUR를 직접 상호 작용하지 않습니다, 그것은 업데이트 AUR 패키지에 대한 귀하의 책임입니다. 를 통해 전체 시스템을 주기적으로 업그레이드 할 때 pacmanAUR PKGBUILD파일에 대한 업데이트를 자동으로 다운로드하여 컴파일 한 후 설치 하지 않습니다 .

이 기사는 AUR에서 패키지를 빌드하는 데 중점을 두지 만 공식 리포지토리에서 직접 패키지를 빌드하는 데 동일한 기술을 사용할 수 있습니다.

PKGBUILD

.spec많은 다른 배포판에서 사용 하는 파일과 비교할 때 a PKGBUILD는 짧고 간단한 셸 스크립트입니다. 일부 패키지는 더 복잡하지만 다음과 유사 할 수 있습니다.

pkgname=NAME
pkgver=VERSION
pkgrel=1
pkgdesc='DESCRIPTION'
url=http://example.com/
arch=('x86_64')
license=('GPL2')
source=(http://example.com/downloads/${pkgname}-${pkgver}.tar.gz)
sha256sums=('f0a90db8694fb34685ecd645d97d728b880a6c15c95e7d0700596028bd8bc0f9')

build() {
   cd "${srcdir}/${pkgname}-${pkgver}"
   ./configure
   make
}

package() {
   cd "${srcdir}/${pkgname}-${pkgver}"
   make install
}

이 문서는 다음을 참조합니다.

• PKGNAME: 패키지 이름
• PKGVER: 패키지 버전 (거의 항상 업스트림 버전 번호와 일치)
• PKGREL: 아치의 "버전" PKGBUILD특정에 대한 PKGVER(변경이 이루어질 수해야하는 경우 증가 일반적으로 1 만 PKGBUILD업스트림 릴리스간에)
• ARCH: 패키지를 빌드 할 수있는 아키텍처 (아치 Linux 공식 저장소는 "x86_64"(64 비트 CPU) 만 지원하므로 AUR 패키지는 여전히 "i686"(32 비트 CPU) 또는 "any"를 지원할 수 있음) 건축을 지정하는 것은 무의미합니다)
• PKGBUILD/ETC: 실제로 AUR 저장소에있는 모든 파일; PKGBUILD및 기타 작은 텍스트 패치, 또는 / 설치 / 제거 쉘 스크립트를 업그레이드합니다. source어레이에 업스트림 파일을 포함하지 않습니다 .

AUR은 매우 신뢰할 수있는 것으로 입증되었지만 신뢰할 수 PKGBUILD/ETC있는 곳에서 소스를 가져 오는지 확인 하는 것이 좋습니다 . (예를 들어, 공식 업스트림 위치는 github에서 올 수 있지만 업스트림 패키지와 관련이없는 임의의 사람의 github 저장소는 아닙니다.) 그리고 PKGBUILD/ETC의심스러운 코드가 포함되어 있지 않습니다.

획득 PKGBUILD/ETC

AUR에서

공식 저장소에 설치하려는 패키지가 없으면 https://aur.archlinux.org/ 에서 검색 하십시오 . 바라건대, 당신은 당신이 찾고있는 것이 존재하고 최신이며 유지된다는 것을 알게 될 것입니다.

를 통해 가장 좋은 방법 PKGBUILD/ETC은를 통해 복제하는 것 git입니다.

git아직 설치 하지 않은 경우 다음을 설치하십시오 .

# pacman -S git

해당 패키지에 대해 AUR 웹 사이트에 표시된 "Git Clone URL"을 사용하십시오.

$ git clone https://aur.archlinux.org/fslint.git

디렉토리를 입력하고 내용을보십시오. (모든 제외하고, 여기에 나열된 . .. .git는 IS PKGBUILD/ETC) :

$ cd <PKGNAME>
$ ls -a
.  ..  .git  PKGBUILD  .SRCINFO

를 살펴보면 PKGBUILD공식 업스트림 소스 코드를 사용하고 패키지를 빌드하는 일반적인 단계를 수행하므로 신뢰할만한 것으로 보입니다. 은 .SRCINFO너무 걱정하지 패키지에 대한 웹 사이트에 표시된 정보가 포함되어 있습니다. 여기에 다른 파일이 있으면 업스트림에서 (직접) 제공 PKGBUILD되지 않으므로 의심되는 파일이 없는지 확인하기 위해 파일과 파일에서 사용 방법을 검사해야합니다.

공식 저장소에서

훨씬 적은 시간이 필요하지만 공식 저장소에 이미 패키지를 구축하여 새 패치를 포함하거나 최신 버전을 구축 할 수 있습니다.

얻기 PKGBUILD/ETC코어와 별도의 저장소에서 :

$ git clone --single-branch --branch "packages/<PKGNAME>" git://git.archlinux.org/svntogit/packages.git "<PKGNAME>"

커뮤니티 저장소에서 :

$ git clone --single-branch --branch "packages/<PKGNAME>" git://git.archlinux.org/svntogit/community.git "<PKGNAME>"

업그레이드 PKGBUILD/ETC

업그레이드 된 버전 PKGBUILD/ETC이 릴리스되면을 사용하여이 디렉토리로 돌아와서 git clone업데이트 할 수 있습니다.

$ git pull

그런 다음 아래에서 선택한 방법을 사용하여 패키지를 다시 컴파일하고 업그레이드하십시오.

컴파일

패키지를 컴파일하는 방법에는 여러 가지가 있습니다. 궁극적으로 모든 것이을 사용합니다 makepkg. 공식적으로 지원되는 두 가지 방법이 있습니다.

• 를 직접 사용하려면 https://www.vultr.com/docs/using-makepkg-on-arch-linux를makepkg 참조 하십시오 .
• makepkg클린에서 간접적으로 사용하려면 https://www.vultr.com/docs/using-devtools-on-arch-linux를chroot 참조 하십시오 .

이 (등 많은 AUR 도우미 프로그램입니다 makepkg같은 공식적으로 아치를 지원하지 않습니다 래퍼),, aurutils, yay, 그리고 최근 중단 aurman하고 yaourt. 이러한 다른 도우미 프로그램 중 하나를 사용하더라도 문제가 발생했을 때 공식적으로 지원되는 방법을 익히는 것이 좋습니다.

이 문서의 나머지 부분은 YOUR BUILDER선택한 방법을 의미 하는 데 사용 됩니다.

로컬 리포지토리

빌드하는 모든 패키지의 중앙 위치가되도록 로컬 저장소를 설정할 수 있습니다.

원하는 곳에 로컬 리포지토리를 배치하십시오.

# mkdir /archLocalRepo

YOUR BUILDER자동 설치 옵션없이 실행 하고 패키지를 로컬 저장소에 복사하십시오.

# cp <PKGNAME>-<PKGVER>-<PKGREL>-<ARCH>.pkg.tar.xz /archLocalRepo

저장소 색인에 새 패키지를 추가하십시오.

# repo-add /archLocalRepo/archLocalRepo.db.tar.gz /archLocalRepo/<PACKAGE-FILE-NAME>

저장소의 색인 및 패키지 파일 자체에서 패키지를 제거하려면 다음을 수행하십시오.

# repo-remove /archLocalRepo/archLocalRepo.db.tar.gz <PKGNAME>
# rm /archLocalRepo/<PACKAGE-FILE-NAME>

기존 패키지 파일을 교체해야하는 경우 교체 할 파일을 별도로 제거한 다음 새 파일을 추가해야합니다. 이전 파일 위에 새 파일을 복사 할 수는 없습니다.

pacman를 편집하여 로컬 저장소를 사용하도록 구성 /etc/pacman.conf하고 끝에 다음을 추가하십시오.

[archLocalRepo]
SigLevel = Optional TrustAll
Server = file:///archLocalRepo

당신이 필요 pacman저장소의 지식을 새로 고침 (지역 포함), 데이터베이스; 추가 한 패키지를 보려면

# pacman -Sy

그런 다음 공식 저장소에있는 경우와 다르게 패키지를 설치할 수 있습니다.

# pacman -S <PKGNAME>

패키지가 설치하려는 다른 패키지의 종속성 인 경우 직접 설치할 필요는 없습니다. 이 다른 패키지를 설치하면 pacman로컬 리포지토리에서 종속성 패키지를 자동으로 찾아 설치합니다.

빠른 컴파일

기본적 YOUR BUILDER으로 단일 스레드를 사용하여 컴파일합니다. 다중 CPU 시스템에서는 가능한 경우 여러 스레드를 사용하도록 허용 할 수 있습니다. 빌드 시스템은 가능하면 소스 코드의 일부를 병렬로 컴파일합니다. 때로는 코드의 일부가 상호 작용하는 다른 부분이 이미 컴파일되어 있어야하므로 허용되는만큼 많은 스레드가 항상 사용되는 것은 아닙니다. 편집 /etc/makepkg.conf.

가상 코어 수만큼 스레드를 사용하려면 다음을 추가하십시오.

MAKEFLAGS="-j$(nproc)"

참고 : 이 명령은 nproc매번 명령을 실행 하므로 Vultr 서버를 업그레이드 할 경우 항상 현재 코어 수를 사용합니다.

전체 시스템 성능에 미치는 영향을 줄이는 등 여러 가상 코어를 사용할 수 있지만 모두 가상 코어를 사용하지 않으려면 특정 수를 추가하십시오. 예를 들어, 코어가 24 개인 경우 21을 사용할 수 있습니다.

MAKEFLAGS="-j21"

보유한 가상 코어 수보다 많은 스레드를 지정하면 성능이 저하됩니다.

매우 드물지만 일부 패키지의 빌드 시스템에는 코드 부분 간의 종속성을 올바르게 정의하지 않아 병렬 컴파일에 문제가 있습니다. 일반적으로 이러한 패키지 PKGBUILD파일은 make -j1설정 한 기본값을 무시하는 을 호출하여이를 처리합니다 . 이것이 필요하고 누락 된 경우 Arch 패키지 관리자에게보고하십시오.

PGP 서명 오류

PKGBUILD소스 배열을 포함 할 수 있습니다 .asc또는 .sig파일입니다. 그것들은 종종 bash 괄호 확장을 사용하여 포함되므로 놓치기 쉽습니다.

source=("http://example.com/downloads/${pkgname}-${pkgver}.tar.gz{,.sig}")

이러한 형식의 서명 파일 중 하나가 소스 배열에 포함 된 YOUR BUILDER경우 업스트림 소스 아카이브의 서명 확인을 자동으로 시도합니다. 서명의 PGP 키는 사용자의 키 링에 있어야합니다. 그렇지 않으면 오류와 함께 중단됩니다.

==> Verifying source file signatures with gpg...
    <SOURCE-FILE> ... FAILED (unknown public key 1234567890ABCDEF)
==> ERROR: One or more PGP signatures could not be verified!

GPG 키는 여러 가지 방법으로 표시 될 수 있음을 이해해야합니다. 지문은 16 진수 40 자이며 항상 사용해야합니다. 긴 키 ID는 마지막 16 자리이며 짧은 키 ID는 마지막 8 자리입니다. 짧아도 편리하지만 서명을 확인하는 데 필요한 모든 추론을 무효화하는 복제가 가능합니다. 게다가 공격자들은 유명 개발자를 위해 더 짧은 키와 일치하는 가짜 키를 생성하는 것으로 알려져 있습니다.

PGP 키 지문 획득 및 확인

패키지 빌드를 아직 시도하지 않은 경우 서명 파일을 포함 할 소스를 다운로드하십시오 (빌드를 시도한 경우 이미 존재 함).

$ makepkg --nobuild --noextract

전체 지문을 얻으려면 :

$ gpg <ASC-OR-SIG-FILENAME>
...
gpg:                using RSA key 155D3FC500C834486D1EEA677FD9FCCB000BEEEE
...

이상적으로는이 지문을 업스트림에서 확인해야합니다. 보안을 유지하려면 업스트림에서 웹 사이트 나 소스 어딘가에 관리자 키를 제공해야합니다. 키 서버에서 키를 검색하는 것만으로는 실제로 아무것도하지 않습니다. 키 서버는 진위 여부를 확인하지 않기 때문에 공격자는 가짜 키를 쉽게 제출할 수 있습니다. 키는 다른 키로 서명 할 수 있으므로 이미 신뢰하는 키가 있으면 서명 한 키를 신뢰하는 것이 안전해야합니다.

특히 업스트림이 지문을 게시하지 않거나 찾기 쉬운 곳에 두지 않는 경우에는 상당한 작업이 될 수 있습니다. 는 PKGBUILD포함 validpgpkeys아치 테이너로 첨가 어레이. 패키지가 공식 저장소 인 경우, 이는 신뢰할 수있는 사용자가 패키지를 배치했음을 의미하며 어레이에 나열된 모든 항목을 신뢰하는 것이 상당히 안전해야합니다. 패키지가 AUR에있는 경우 다른 아치 사용자가 패키지를 배치했음을 의미합니다. 당신이 그것을 신뢰하는 것에 대해 걱정한다면, 당신은 항상 사용자가 과거에 아치로 무엇을했는지 볼 수 있습니다.

열쇠 고리에 PGP 키 추가

열쇠 고리에 지문을 추가하려면 :

$ gpg --recv-keys <FINGERPRINT>

이제를 실행할 수 있으며 YOUR BUILDER지문을 신뢰합니다.

AUR 개발 패키지

끝나는 이름을 가진 AUR 패키지 -git, -svn, -bzr또는 -hg상류 최신 버전의 상류의 최신 버전 제어 시스템을 사용할 수 있습니다 개발 버전을 대신 커밋합니다. 예를 들어-git패키지는 마스터 브랜치 (또는 이와 동등한 브랜치)에서 업스트림의 최신 커밋을 사용합니다. 이것은 아직 릴리스되지 않은 업스트림 버그 수정 및 새로운 기능을 실행하는 경우에 유용하며, 아직 릴리스되지 않은 커밋으로 수정 된 버그가 아닌지 확인해야합니다. 이러한 패키지는 잠재적으로 불안정한 것으로 간주해야합니다. 불행히도 일부 업스트림 관리자는 릴리스에 태그를 지정하지 않거나 태그 릴리스 사이에 너무 오래 갈 수 없으며 모든 사람이 최신 커밋을 사용하기를 기대하기 때문에 대안이 없습니다. 패키지에 따라 해당 커밋을 실행 한 첫 번째 사람이 될 수 있습니다. 업스트림 개발자에 따라 최신 커밋이 컴파일되지 않을 수도 있습니다.

일반적인 실수를 이해하는 것이 중요합니다. 단순히 이전 버전 번호를 표시하기 때문에 AUR 개발 패키지를 오래된 것으로 표시하지 마십시오! 개발 패키지 PKGBUILD파일에는 업스트림 소스 코드에서 pkgver()업데이트 된 업데이트를 자동으로 구문 분석하는 데 사용되는 추가 기능이 포함되어 있습니다 PKGVER. -git패키지 의 일반적인 형식 은 <TYPICAL-VERSION-NUMBER>.r<COMMITS-SINCE-LAST-RELEASE>.<GIT-COMMIT>-<PKGREL>입니다. 패키지는 같은 AUR에 표시 될 수 있습니다 5.0.0.r102.8d7b42ac21-1즉 그 무엇이기 때문에, PKGBUILD이 포함되어 있습니다. 그러나 패키지를 만들면 새로 다운로드 한 소스 코드를 반영하도록 YOUR BUILDER자동으로 업데이트 PKGVER됩니다. 실제로 많은 새 버전이 릴리스되었지만 빌드 프로세스에서 변경된 사항이없는 PKGBUILD경우 이전 버전을 나열하면 다음과 같이 훨씬 더 새로운 것을 빌드 할 수 있습니다.9.1.2.r53.2c9a41b723-1. 이러한 패키지의 경우 웹 사이트에 나열된 버전은 AUR 관리자가 마지막으로 업데이트해야 할 당시의 최신 버전 PKGBUILD입니다.

AUR 관리자는 PKGVER새 버전�� 반영하기 위해 업데이트 만하지 않습니다 . 새로운 업스트림 커밋이 실제로 다른 PKGBUILD것을 변경 해야 할 때만 그렇게해야합니다 .

실제로 잘못된 것을 알고있는 경우 개발 AUR 패키지를 오래된 것으로 표시하십시오. 즉, 실제로 사용하려고 시도했으며 올바르게 형식이 지정된 new 컴파일 또는 구문 분석에 실패했습니다 PKGVER. PKGBUILD업스트림 의존성 변경, configure옵션 변경, ���로운 GCC 버전이 이전 버전의 소스 코드에서 오류가 발생했거나 업스트림 저장소 위치가 변경되거나 업스트림 개발자가 일반적인 버전의 위치를 ​​변경 하는 등 AUR 관리자가 업데이트하도록 강제하는 상황이 발생하는 경우 가 있습니다. 소스 코드 내에PKGVER구문 분석 기능. 컴파일 또는 작동에 실패하더라도 AUR 유지 관리자가 빌드 프로세스를 변경해야하거나 AUR 유지 관리자가 책임을지지 않는 소스 코드의 업스트림 문제 일 수 있음을 이해하십시오.

오래된 패키지

패키지가 오래되었다고보고하기 전에 위의 "AUR 개발 패키지"섹션을 읽으십시오!

업스트림이에서보다 개발되지 않은 패키지의 최신 버전을 출시 한 경우 PKGBUILD"Flag package out of old"를 클릭하고 관리자에게 메시지를 입력 할 수 있습니다. 공식 저장소 패키지에는 https://packages.archlinux.org 를, AUR 패키지 에는 https://aur.archlinux.org 를 사용 하십시오 . 유용한 메시지는 새 버전 번호이며 릴리스 발표 또는 소스 코드에 대한 링크 일 수 있습니다. 신고 기능은 메시지를 관리자에게 자동으로 이메일로 보냅니다.

AUR 패키지에서 2 주 후에도 응답이없는 경우 신뢰할 수있는 사용자에게 현재 관리자에게 제거를 요청하고 패키지가 분리되도록하려면 "Orphan"유형의 "요청 제출"을 클릭하십시오. 관리자가 고아 요청에 응답하지 않습니다. 일반적으로 사람들은 고아 요청을 제출할 수 있고 패키지를 인수 할 의향이있는 경우에만 가능하며 이미 작동중인 전류가있는 경우에만 요청합니다 PKGBUILD.

그 동안 종종 오래된 패키지를 직접 업데이트 할 수 있습니다. 종종 새 버전 번호 PKGBUILD로 업데이트하여 a 만 변경하면 PKGVER무결성 합계가 업데이트됩니다. 프로그램 updpkgsums은 package에 존재하며 pacman-contrib, 합계가 자동으로 계산되어 자동으로 업데이트됩니다 PKGBUILD. 새 버전의 설치 과정에서 변경해야 할 사항이 있는지 확인하려면 업스트림 릴리스 정보를 확인하는 것이 좋습니다. 때때로 업스트림 변경에는 더 많은 변경 또는 점검이 필요합니다 PKGBUILD/ETC. 종종 source어레이가 내장 PKGVER되어 있으므로 종종 업데이트 할 필요가 없습니다.