우분투 소스가 제공 될 때 자동으로 패치하여 PPA에 업로드하는 쉬운 방법이 있습니까? 소스에 적용 패치를 올바르게 커밋하십시오 ( dpkg-source –commit

다음을 수행 할 수있는 도구를 찾고 있습니다.

  • 소스 패키지 세트 (특히 gtk + 2 및 gtk + 3)에 대한 업데이트 자동 감지
  • 소스 패키지를 다운로드
  • 나만의 맞춤형 패치를 소스에 적용
  • 패치를 올바르게 커밋하십시오 ( dpkg-source --commit [something-or-other]?).
  • 성공적으로 실행하면 Launchpad의 PPA에 업로드합니다 (일반적인 방식으로 시스템을 가리킬 수 있음).

런치 패드가 저를 위해 그 모든 것을 할 수 있습니까?

그렇지 않은 경우 cron 작업에서 자동으로 모든 작업을 수행하는 도구가 있습니까?

위의 내용에 실패하면 직접 무언가를 노크하지만 어떤 명령을 수행해야합니까?

  • 소스 패키지 업데이트를 감지하고 다운로드합니까? (매번 새로운 사본을 소스로 가져 오는 대신 (bzr | git) 풀과 같은 것을 선호합니다)
  • 패치를 로컬에서 자동 커밋 (매번 동일한 커밋 설명을 사용함)?
  • PPA에 비대화 형 소스를 업로드 하시겠습니까?

질문이 (발견했습니다 사용자 정의 PPA를 위해 와인을 패치하는 적절한 방법은 무엇? 비슷하지만 대답의 단계는 여전히 기본적으로 수동 및 대화 형). 소스 업데이트의 자동 감지와 그에 대한 완전 자동 버전은 많은 도움이 될 것입니다.



답변

음, 같은 소리 요리법 포장 여기에 갈 수있는 방법입니다. 기본적으로 패키징 레시피는 런치 패드의 bzr 브랜치가 변경 될 때마다 자동으로 Ubuntu 소스 패키지를 작성하여 PPA에 업로드 할 수 있습니다. 온라인 설명서는 아주 좋은 것입니다,하지만 난 몇 가지 예를주지 …

먼저 추적 할 분기를 지정하고 (예 lp:gtk3🙂 자신의 데비안 패키징 분기를 해당 분기에 중첩시키는 명령을 추가합니다. Inkscape의 일일 빌드를 위해 만든 이 레시피를 살펴보십시오 .

# bzr-builder format 0.4 deb-version 1:0.48+devel+{revno}+{revno:packaging}
lp:inkscape
nest packaging lp:~inkscape.dev/inkscape/debian-packaging debian

이 레시피는 Inkscape의 최신 업스트림 소스를 사용하여 매일 Ubuntu 패키지를 작성하지만 lp:~inkscape.dev/inkscape/debian-packaging분기 에서 사용자 정의 된 Debian 패키징 지시 사항을 ” debian” 라는 서브 폴더로 복사 합니다.

런치 패드의 패키징 레시피 페이지에서 패키지를 자동으로 업로드 할 PPA를 지정할 수 있습니다. 우리의 경우에는 여기 에 업로드 됩니다 .

다른 방법으로, 기존 소스를 사용하지 않고 기존 Ubuntu 패키지를 사용하여 레시피를 만들 수 있습니다. 예를 들면 다음과 같습니다 lp:ubuntu/gtk+3.0. 그런 다음이 코드의 브랜치를 작성하고 필요한 수정 사항을 커밋해야합니다. lp:~myaccount/ubuntu/saucy/gtk+3.0/my-custom-build예를 들어 봅시다 . 그런 다음 네스트 패키징 지시 사항 대신 변경 사항 을 자동으로 병합 하는 레시피를 작성합니다 . 레시피는 다음과 같습니다.

# bzr-builder format 0.4 deb-version {debversion}+{date}
lp:ubuntu/gtk+3.0
merge my-custom-build lp:~myaccount/ubuntu/saucy/gtk+3.0/my-custom-build

따라서이 레시피는 사용자 정의 Ubuntu 소스 패키지를 자동으로 빌드하고 공식 Ubuntu 패키지가 변경 될 때마다 PPA에 업로드합니다.

이 “병합”접근 방식을 취하면 패치를 적용하기위한 두 가지 옵션이 있습니다. 브랜치에서 업스트림 소스 코드를 직접 편집하고 bzr이 병합을 처리하도록하거나 debian/퀼트를 사용 하여 폴더 내에 패치 파일을 만들 수 있습니다 . 각각의 장점 / 단점이 있습니다. 전자의 접근 방식은 조금 더 똑똑합니다. 패치 중 하나가 업스트림 개발자에 의해 채택되면 병합은 여전히 ​​작동하며 우분투 패키지는 정상적으로 빌드됩니다. 후자의 방법을 사용하면 패키징 코드를 업스트림 코드와 분리하는 표준 데비안 기반 접근 방식을 사용하여 패치를 처리 할 수 ​​있지만 업스트림 개발자가 패치 중 하나를 채택하면 퀼트는 (중복)을 적용 할 수 없습니다 패치 및 패키지 빌드에 실패합니다.