여러 다른 패키지에 의존하는 패키지를 구축하는 데 문제가 있습니다. 그 중 일부에는 서비스가 포함되어 있습니다. 문제의 서비스가 postinst 스크립트에서 시작을 시도하는데, 이로 인해 systemd서비스가 빌드 환경에 설치되지 않아 빌드가 실패하게 됩니다.
비슷한 문제가 있는 일부 공식 패키지를 살펴보고 싶습니다. 이 시점에서는 종속성 서비스를 실행할 필요가 없지만 postinst 스크립트는 여전히 작동해야 합니다(당연히?!). 이 경우 이름이 패키지 이름과 다르기 때문에 서비스를 수동으로 시작하려고 합니다(게다가, 실제로 해당 패키지 2 서비스에 뭔가가 있지만 저는 빗나갔습니다).
내 스크립트는 현재 다음을 수행하려고 합니다.
systemctl enable ipload
systemctl start ipload
Ubuntu 시스템에 패키지를 설치할 때는 제대로 작동하지만 -dev해당 패키지에 의존하는 시스템을 구축할 때는 실패합니다.
내 질문은 다음과 같습니다
비슷한 문제가 있는 기존 공식 데비안 패키지가 있습니까? 일반적으로 서비스를 시작하고 빌드에 필요한 다른 패키지에 의존합니까?
이렇게 하면 비슷한 방식으로 나만의 패키지를 만들 수 있습니다.
답변1
dh_installsystemd서비스를 설정하려면 패키지 빌드에서 이를 사용해야 합니다 . 이렇게 하면 관리자 스크립트에서 적절하게 신뢰할 수 있는 코드 조각이 생성됩니다. 예시 보기g810-led~의debian/rules;패키지 이름과 일치하지 않는 유닛을 처리하는 방법을 보여줍니다.
dh_installsystemd --no-stop-on-upgrade --no-start --name=g810-led-reboot
--no-stop-on-upgrade( 또는 를 사용하면 안 됩니다 --no-start.)
결과에는 다음 postinst이 포함됩니다.
# Automatically added by dh_installsystemd/13.3.4
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
# This will only remove masks created by d-s-h on package removal.
deb-systemd-helper unmask 'g810-led-reboot.service' >/dev/null || true
# was-enabled defaults to true, so new installations run enable.
if deb-systemd-helper --quiet was-enabled 'g810-led-reboot.service'; then
# Enables the unit on first installation, creates new
# symlinks on upgrades if the unit file has changed.
deb-systemd-helper enable 'g810-led-reboot.service' >/dev/null || true
else
# Update the statefile to add new symlinks (if any), which need to be
# cleaned up on purge. Also remove old symlinks.
deb-systemd-helper update-state 'g810-led-reboot.service' >/dev/null || true
fi
fi
# End automatically added section
이는 deb-systemd-helper가 있든 없든 설치를 처리하는 데 사용됩니다 systemd.
또한 해당 prerm합계 도 볼 수 있습니다 postrm.
-dev그러나 패키지가 궁극적으로 패키지 배송 서비스에 의존하는 경우는 흔하지 않습니다(전례는 아니지만). 콘텐츠를 더 분할할 수도 있습니다(예: -dev패키지, 라이브러리 패키지, 서비스가 포함된 패키지).
답변2
나는 얻기가 어렵다dh_installsystemd작업을 하기 위해 완벽하게 만들기 위해 취한 다양한 단계에 대한 나만의 답변을 갖고 싶습니다(거의 1).
길게 만들어
디테일을 켜지 않는 한 작업 중 기능의 흔적은 매우 가벼울 수 있습니다. 이는 파일 에 다음을 추가하여
debian/rules수행됩니다 .export DH_VERBOSE=1디버깅이 완료된 후 삭제하거나 주석 처리하세요.
파일을 다음 위치에 배치하세요.
debian/...내 원본 게시물에서 파일은 다음과 같이 정의됩니다
contrib/ipload.service. 파일을 설치 중입니다.손으로(해당 파일 사용iplock.install) 그런 다음systemctl명령을 사용하여 서비스²를 설정합니다.systemd에서 제공하는 debhelpers와 함께 사용하려면
debian/...다음과 같이 파일을 이동해야 합니다.git mv contrib/ipload.service debian/iplock.ipload.service이름이 어떻게 바뀌는지 확인하세요. 이제 세 부분으로 나누어집니다.
iplock--서비스를 추가하려는 패키지의 이름ipload-- 서비스 파일명 (이전과 동일)service--systemd 파일 유형, 서비스
호환성 수준이 올바른지 확인하세요.
이제 호환성 수준을 정의하는 방법에는 두 가지가 있습니다. 오래된 방법은 파일을 갖는 것입니다
debian/compat. 파일에는 단 하나의 레벨만 포함됩니다(예: 12와 같은 십진수를 포함하는 테스트 파일).debhelper-compat새로운 방법은 파일에 종속성을 만드는 것입니다debian/control.Build-Depends: debhelper-compat (= 12), ...어느 쪽이든 최소 12개인지 확인하세요. 그렇지 않으면 시스템화된 debhelpers를 덮어쓰게 됩니다.확실히완전히 시작하세요(무시됩니다). 오래 전에 패키지를 만들었다면 더 낮은 호환성 수준을 사용하는 것이 불가능하지 않습니다.
서비스 파일의 실제 설치
많은 프로젝트와 달리 이 프로젝트에는 두 개의
.service파일이 있습니다. 하나가 호출되어 패키지ipwall.service에 들어갑니다 .ipwall위에서 언급한 것처럼 다른 하나는 이름이 지정 되어 패키지ipload.service에 넣어야 하는 반면, 두 번째 하나는 이름 불일치로 인해 실패합니다.iplock위에서 언급했듯이 먼저 파일 이름을 올바르게 변경해야 했습니다(
<package name>.<service name>.<extension>). 그런 다음 다음과 같이 재정의해야 합니다.override_dh_installsystemd: dh_installsystemd dh_installsystemd --name=ipload첫 번째 호출은 올바르게
dh_installsystemd설치됩니다ipwall(실제로는 평소와 같이 모두 기본값입니다). 두 번째 호출은 이름(ipload)을 지정하고 그것이 설치된 것입니다... 물어볼 수도 있습니다. ! 이는 위에서 언급한 파일 이름으로 정의되므로iplock.ipload.service에 설치됩니다iplock.
1 내가 말했지거의사용자가 생성되고 서비스가 시작된 다음 설정이 업데이트되기 때문에 여전히 문제가 있기 때문입니다. 따라서 처음 실행 시 기본 설정이 사용되며 관리자 변경이 필요하지 않습니다. 한 번에 하나의 질문인 것 같아요.
² 이는 빌드 시스템에 systemd가 설치되지 않았기 때문에 이전에 겪었던 문제입니다. 스크립트는 시스템 도구를 사용하기 전에 실제로 디렉토리를 테스트합니다 /run/systemd/system.
if [ -d /run/systemd/system ]
then
...here you can use systemctl...
fi