Czy istnieje prosty sposób na automatyczne łatanie źródeł ubuntu, gdy stają się one dostępne i przesyłane do PPA?


9

Szukam narzędzia do wykonania następujących czynności:

  • Automatycznie wykrywaj aktualizacje zestawu pakietów źródłowych (w szczególności gtk + 2 i gtk + 3)
  • pobierz pakiet źródłowy
  • zastosuj moje własne łatki do źródła
  • zatwierdzić poprawkę poprawnie ( dpkg-source --commit [something-or-other]?)
  • jeśli się powiedzie, prześlij je do PPA na Launchpad (do którego mogę następnie skierować mój system w zwykły sposób).

Czy Launchpad może to wszystko dla mnie zrobić?

Jeśli nie, to czy istnieje narzędzie, które automatycznie wykona to wszystko z zadania cron?

W przeciwnym razie sam coś powalę, ale jakich poleceń potrzebuję:

  • wykryć i pobrać aktualizacje pakietu źródłowego? (Wolałbym coś takiego jak (bzr | git) pull zamiast konieczności apt-get source za każdym razem nowej wersji)
  • automatyczne zatwierdzanie łatki lokalnie (używałbym tego samego opisu zatwierdzenia za każdym razem)?
  • przesyłać źródła w sposób nieinteraktywny do PPA?

Znalazłem pytanie ( jaki jest właściwy sposób na załatanie Wine dla niestandardowego PPA? ), Które jest podobne, ale kroki w odpowiedzi są w zasadzie ręczne i interaktywne. Bardzo praktyczna wersja tego plus automatyczne wykrywanie aktualizacji źródła bardzo by pomogło.

Odpowiedzi:


2

Wygląda na to, że przepisy kulinarne na opakowania są tutaj. Zasadniczo przepisy na opakowania mogą automatycznie tworzyć pakiety źródłowe Ubuntu i przesyłać je do PPA za każdym razem, gdy zmienia się gałąź bzr na Launchpad. Dokumentacja online jest całkiem dobra, ale podam kilka przykładów ...

Najpierw określasz gałąź do śledzenia (na przykład lp:gtk3), a następnie dodajesz polecenie zagnieżdżenia własnej gałęzi pakowania Debiana w tej gałęzi. Spójrz na ten przepis, który stworzyłem dla codziennych wersji 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

Ten przepis tworzy pakiet Ubuntu każdego dnia przy użyciu najnowszego źródła dla Inkscape, ale kopiuje spersonalizowane instrukcje pakowania Debiana z lp:~inkscape.dev/inkscape/debian-packagingoddziału do podfolderu o nazwie „ debian”.

Strona z przepisami dotyczącymi opakowań na pasku Launchpad pozwala określić, do którego PPA mają być automatycznie przesyłane pakiety. W naszym przypadku jest on przesłany tutaj .

Alternatywnie możesz oprzeć swój przepis na istniejącym pakiecie Ubuntu, a nie bezpośrednio na źródłowym źródle. Na przykład lp:ubuntu/gtk+3.0. Musisz wtedy utworzyć gałąź tego kodu i dokonać wymaganych modyfikacji. Nazwijmy to lp:~myaccount/ubuntu/saucy/gtk+3.0/my-custom-buildna przykład. Następnie należy utworzyć przepis, aby automatycznie scalić zmiany zamiast zagnieżdżać instrukcje pakowania. Przepis wyglądałby mniej więcej tak:

# 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

Dlatego ten przepis automatycznie tworzy niestandardowy pakiet źródłowy Ubuntu i przesyła go do Twojego PPA, ilekroć nastąpi zmiana w oficjalnym pakiecie Ubuntu.

Jeśli zastosujesz to podejście „scalania”, masz dwie możliwości zastosowania poprawek. Albo po prostu edytuj kod źródłowy bezpośrednio w swoim oddziale i pozwól bzr zająć się jego scaleniem, lub możesz utworzyć pliki łatek w debian/folderze za pomocą kołdry. Każdy ma swoje zalety / wady. Pierwsze podejście jest nieco mądrzejsze ... jeśli jedna z twoich łatek zostanie przyjęta przez programistę wyższego szczebla, wówczas scalanie zwykle będzie nadal działać, a pakiet Ubuntu zbuduje się OK. To drugie podejście pozwala obsługiwać łatki przy użyciu standardowego podejścia opartego na Debianie, polegającego na oddzieleniu kodu opakowania od kodu źródłowego ... jednak jeśli programista źródłowy zastosuje jedną z łat, kołdra nie będzie w stanie zastosować (duplikatu) łatka, a pakiet nie zostanie skompilowany.


Ale którą wersję GTK-3 lp:ubuntu/gtk+3.0śledzi? Aktualna stabilna czy aktualna wersja rozwojowa?
Khurshid Alam,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.