Obsługuje obsługę pakietów innych niż Ubuntu

Od tygodnia czytam o apport i jego użyciu. Ale nie mogłem zrozumieć poniższych rzeczy.

Scenariusz:

Opracowałem aplikację i spakowałem ją. I nazywa się MyApp.deb. Nazwa pakietu binarnego to MyApp. Aplikacja jest instalowana na ścieżce /opt/myapplication/bin/MyApp.

Wymaganie:

1. Kiedy moja aplikacja ulega awarii, chcę mieć możliwość zebrania zrzutu pamięci.
2. Przy każdej kolejnej awarii musi utworzyć nową, ale nie zastępować istniejącej. Pomogłoby mi coś takiego jak automatyczna zmiana nazwy z aktualnym znacznikiem czasu itp.
3. Kiedy instaluję aplikację na komputerze klienta, mój instalator nie może modyfikować parametrów całego systemu. Powiedzmy na przykład, że nie wolno mi zmieniać schematu generowania jego podstawowego pliku, ponieważ użytkownik / klient może nienawidzić mojej aplikacji, ponieważ zmieniłbym jego parametry systemowe bez jego zgody.
4. Nie mam nic przeciwko ścieżce generowania plików rdzenia. Bieżący katalog lub/var/crash

Rzeczy, które do tej pory odkrywałem:

Apport to ładne narzędzie, które umożliwia generowanie podstawowych plików. Za pomocą /proc/sys/kernel/core_patternmogę sformatować podstawowe pliki. Zapewnia to elastyczność przekierowywania plików podstawowych do wstępnie zdefiniowanego katalogu, nadawania nazw plikom podstawowym z pid, dołączania lub dołączania wzorca ścieżki pliku itp. W przypadku pakietów innych niż Ubuntu muszę pisać haki, aby wygenerować zrzuty pamięci (raporty) . Apport po zebraniu raportu zostanie przesłany.

Rzeczy, których nie rozumiem:

1. Czy to Apport, na który muszę patrzeć? Mam na myśli, czy to wystarczy mojemu celowi? A może powinienem patrzeć na coś innego?
2. Jakiego rodzaju pakiet obejmuje moja aplikacja? Czy nazywam to non-ubuntu? Trzecia część? co to jest? Widzę różne terminologie w dokumentach?
3. Jak wspomniałem, MyAppdziała z /opt/myapplication/bin/MyApp, więc gdzie będą generowane pliki podstawowe? Aktualny reż czy /var/crash? Czy Apport wykrywa awarie wyzwolone /opt? Czy to interpretuje?
4. Ważne pytanie: jeśli opracowałem aplikację i jeśli Apport prześle raport do repozytoriów Ubuntu, nie ma to sensu. Jak więc mogę powiedzieć Apportowi, żeby przysłał mi raport?
5. Otrzymuję ten błąd: executable does not belong to a package, ignoring. Więc co robię źle?
6. Aby program apport mógł rozpoznać mój pakiet, czy muszę go uczynić pakietem źródłowym? Czy to jest obowiązkowe? Chcę tylko utworzyć pakiet binarny?
7. Widziałem także gdzieś w dokumentach, które rozpoznaje Apport:
   1. Pakiety Ubuntu lub
   2. Aplikacje uruchamiające, ale moja aplikacja nie jest żadna z nich. Więc w jaki sposób Apport pomaga mi w bieżącym scenariuszu?

1. Wygląda blisko, ale może nie być tym, czego potrzebujesz. Apport automatycznie zmienia / proc / sys / kernel / core_pattern. Więc jeśli nie da się tego zmienić, nie masz szczęścia. Z drugiej strony apport jest teraz domyślną instalacją Ubuntu, więc praktycznie wszyscy używający Ubuntu już zmienili ten parametr. Nie znam też żadnego sposobu, aby powiedzieć apportowi, aby zatrzymywał więcej niż najnowszą awarię z określonej aplikacji, ale dopóki przesyłana jest każda awaria, nie stanowi to problemu.
2. Nazywałbym to podmiotem zewnętrznym.
3. Apport obsługuje pliki wykonywalne zainstalowane w / opt. Musisz podać podpięcie / opt / path / to / your / app / share / apport / package-hooks.
4. Możesz ustawić niestandardową bazę danych awarii w haku pakietu dla swojego pakietu. Ale jeśli baza danych awarii nie działa jak debbugs lub launchpad, musisz także utworzyć niestandardową implementację konektora bazy danych awarii, co nie wygląda na to, że można tego dokonać bez instalowania pliku python poza / opt.
5. Plik wykonywalny musi zostać zainstalowany przez dpkg, co oznacza, że ​​musisz spakować go do pliku .deb.
6. Musisz utworzyć pakiet źródłowy, aby utworzyć pakiet binarny, ponieważ pakiety binarne są tworzone z pakietów źródłowych. Nie musisz dystrybuować pakietu źródłowego.
7. Apport działa ze wszystkim, co jest spakowane jako plik .deb.