☰

rpm 에뮬레이션 - 복잡한 rpm 빌드

tag-icon • tag-icon rpm rpm-spec mock
rpm 에뮬레이션 - 복잡한 rpm 빌드

자체 OpenSSL을 갖춘 Apache 웹 서버를 제공하는 RPM을 만들고 싶다고 가정해 보겠습니다.

/mydir/apache_postfix1
/mydir/openssl_postfix1

configure --prefix=/mydir/opensslmakeApache mod_ssl에는 실제 OpenSSL 설치가 필요하므로 Apache가 실제로 컴파일할 수 있도록 OpenSSL을 설치해야 했습니다 .make install/mydir/opensslmod_sslconfigure --with-ssl=/mydir/openssl

이는 작업 디렉터리 외부에 대한 권한이 없기 때문에 빌드 서버(Jenkins)에서는 생각할 수 없는 일입니다. 하지만 OpenSSL을 사용하여 Apache를 빌드하고 이를 RPM으로 패키징해야 합니다(각각 자체 OpenSSL이 있는 접미사 여러 Apache를 제공하려면).

그래서 저는 이것이 mock해결책이라고 생각합니다(사용자/설치 권한을 얻는 것보다 빌드 서버에 설치할 가능성이 더 높습니다).

그러나 모의를 사용하여 rpmbuild의 전체 기능을 사용하는 방법에 대한 완전한 문서를 찾지 못했습니다.

시도해 보았지만 실패하는 것 mock -r epel-7-x68_64 example.src.rpm같습니다 /builddir/build/SPECS/example.spec. 왜죠? 이 파일은 어디서 가져오나요?

이는 단지 예일 뿐이며 실제 문제는 단일 서비스로 작동하도록 서로 구성/컴파일되어야 하고 Red Hat Satellite를 200개 이상의 서버에 전달하기 위해 단일 RPM으로 패키징해야 하는 7개의 개별 패키지로 구성됩니다. ..실제로 빌드 서버에 설치하지 않고...

사용 가능한 문서/예제에 대한 도움이나 링크를 주시면 감사하겠습니다!

답변1

가장 좋은 문서 소스는 다음과 같습니다.시뮬레이션 소스 코드, 이것공식 rpm 문서, 이것rpm 패키징 가이드및 권장되는 추가 문서. 게시한 예에서는 example.src.rpm시뮬레이션을 사용할 수 있도록 패키지의 올바른 위치에 적절한 사양 파일이 없는 것 같습니다 .

시뮬레이션은 src.rpm 파일의 입력으로 다시 빌드되거나 사양 파일 및 소스 디렉터리를 사용하여 소스 rpm(SRPM)을 빌드할 수 있습니다. 일부 추가 구성을 사용하면 소스 코드 체크아웃에서 직접 모의 객체를 사용할 수도 있습니다. 가장을 설치하고 이를 사용하도록 사용자를 구성한 후에는(루트로 사용하려고 하면 가장이 불만을 표시하며 권한 없는 사용자는 가장 그룹에 있어야 함) 사용이 매우 간단합니다.

yumdownloader --source openssl
mkdir rpm-results
mock -r epel-7-x68_64 --resultdir=rpm-results openssl-*.src.rpm

그러면 OpenSSL을 제공하는 배포판이 다시 빌드되고 결과 패키지가 rpm-results 디렉터리에 배치됩니다. 배포판에서 제공하는 패키지를 변경하려면 src.rpm을 설치하고 변경한 다음 결과 rpm 파일을 빌드해야 합니다.

yumdownloader --source openssl
rpm -ivh openssl-*.src.rpm
# usually this installs to ~/rpmbuild
# make your changes to ~/rpmbuild/SOURCES/* and ~/rpmbuild/SPEC/openssl.spec as necesary
mkdir rpm-results
mock -r epel-7-x68_64 --resultdir=rpm-results --buildsrpm ~/rpmbuild/SPEC/openssl.spec
mock -r epel-7-x68_64 --resultdir=rpm-results rpm-results/openssl-*.src.rpm

최신 버전에 2단계 빌드(SRPM => RPM)가 필요하지 않은지 확실하지 않지만 이것이 우리 매장에서 모형을 사용하는 방식입니다. 다시 빌드하려는 각 패키지에 대해 이 작업을 원하거나 수행해야 할 수도 있습니다. 나는 당신이 요구하는 것처럼 모든 것을 하나의 패키지로 묶는 것을 권장하지 않지만 기술적으로는 그렇게 하는 것을 막을 수 없습니다. 자신만의 사양 파일을 만들고 모든 것을 함께 결합하거나 다음과 같은 다른 도구를 사용하면 됩니다.플루오로메틸메타크릴레이트.

답변2

저는 Mock의 관리자이므로 답변을 드리고 싶습니다. 하지만 정확히 문제가 무엇인지 지정하지 않았기 때문에 정말 할 수 없습니다.

나는 Mock이 어떻게 작동하는지에 대해서만 자세히 설명하고 여러분의 혼란을 해결할 수 있습니다.

호출할 때 조롱하세요 mock -r fedora-27-x86_64(지루한 세부 사항은 생략).

  1. dnf install --installroot /var/lib/mock/fedora-27-x86_64/root @buildsys-build이렇게 하면 별도의 디렉터리에 최소 시스템이 설치됩니다. 이 답변에서는 $CHROOT라고 부르겠습니다 /var/lib/mock/fedora-27-x86_64/root.

  2. 시뮬레이션 은 example.src.rpm.​$CHROOT/builddir/build/SPECS$CHROOT/builddir/build/SOURCES

  3. Mock은 사양 파일을 구문 분석하고 BuildRequires에 나열된 모든 패키지를 $CHROOT에 설치합니다. (이것은 루트로 수행됩니다).

  4. 그러면 Mock은 $CHROOT로 chroot()하고 그곳에서 실행됩니다 rpmbuild -ba /builddir/build/SPECS/example.spec. 이는 권한이 없는 사용자(UID가 귀하의 UID와 동일함)로 수행됩니다. 이는 rpmbuild 실행이 항상 권장되지 않으며 심각한 문제를 일으킬 수 있기 때문에 수행됩니다.

따라서 chroot에 일부 추가 패키지를 설치하려면 yum/dnf install을 호출하여 spec 파일에서 설치하면 안 됩니다(특히 rpm은 재진입이 아니기 때문에). 하지만 BuildRequires에서 이러한 패키지를 지정하고 이러한 패키지가 포함된 저장소를 제공해야 합니다.

mockchain -a REPOS(모의 체인은 모의 체인 위에 있는 얇은 레이어임)을 사용하거나 다음을 통해 저장소를 제공할 수 있습니다.

cp /etc/mock/fedora-27-x86_64.cfg ~/my-custom-fedora-27-x86_64.cfg
#add your repository to ~/my-custom-fedora-27-x86_64.cfg
mock -r ~/my-custom-fedora-27-x86_64.cfg example.src.rpm

서로 의존하는 7개의 src.rpm 패키지가 있는 경우 가장 좋은 접근 방식은 mockchain 1.src.rpm 2.src.rpm .... 7.src.rpm결과의 임시 저장소를 생성하고 while at-least-one-package-build do another loop.

실제 문제가 무엇인지 지정해 주시면 보다 구체적인 답변을 드릴 수 있습니다.

관련 정보