Instalacja z QNapi z kodów źródłowych

[micdnj]

Cześć,

udało mi się skompilować z kodów źródłowych program QNapi, ale mam pytanie co dalej?

Poniżej wkleiłem jak wygląda struktura katalogów programu. I jak rozumiem są takie opcje:
1. mogę po prostu wgrać te pliki jako root w strukturę /usr/
2. lepiej, jak bym zrobił paczkę i zainstalował ją przez dnf. Ale chyba kupa roboty z tym jest
3. ale jest też w Fedorze katalog /opt, gdzie jak rozumiem lądują jakieś niesystemowe aplikacje, jak ta. Z tym że jak wtedy zrobić, żeby ikony, help, i plik qnapi.desktop były widoczne i poprawnie interpretowane przez system?
 
Jak najlepiej do tego podejść?

Byłbym wdzięczny za rozszerzenie mojej linuxowej wiedzy. Z góry dzięki.

.
└── usr
    ├── bin
    │   ├── qnapi
    │   └── qnapic
    └── share
        ├── applications
        │   └── qnapi.desktop
        ├── doc
        │   └── qnapi
        │       ├── ChangeLog
        │       ├── COPYRIGHT
        │       ├── LICENSE
        │       ├── LICENSE-pl
        │       ├── qnapi-download.desktop
        │       ├── qnapi-download.schemas
        │       ├── qnapi-scan.desktop
        │       └── qnapi-scan.schemas
        ├── icons
        │   └── hicolor
        │       ├── 128x128
        │       │   └── apps
        │       │       └── qnapi.png
        │       ├── 16x16
        │       │   └── apps
        │       │       └── qnapi.png
        │       ├── 32x32
        │       │   └── apps
        │       │       └── qnapi.png
        │       ├── 48x48
        │       │   └── apps
        │       │       └── qnapi.png
        │       └── 512x512
        │           └── apps
        │               └── qnapi.png
        └── man
            ├── it
            │   └── man1
            │       └── qnapi.1.gz
            ├── man1
            │   └── qnapi.1.gz
            └── pl
                └── man1
                    └── qnapi.1.gz

[pavbaranov]

Czy istniała jakaś konkretna potrzeba kompilacji? RPM z QNapi przecież jest dla Fedory, np.: https://fedora.pkgs.org/37/rpm-sphere-x86_64/qnapi-0.2.3-1.1.x86_64.rpm.html. Masz też appimage: http://qnapi.github.io/#download
Jeśli istniała, to jak to kompilowałeś? Mi to wygląda na (z katalogu z rozpakowanymi źródłami):

Kod [Zaznacz] Rozwiń

qmake
make
sudo make installI to winno spowodować instalację zbudowanej paczki w domyślnym katalogu (tam, gdzie system winien widzieć binarki).

[micdnj]

A widzisz.... Szukałem qnapi przez

Kod [Zaznacz] Rozwiń

dnf search qnapii w ten sposób nie znalazłem, więc uznałem że nie ma. A widzę że nie mam podpiętego repozytorium gdzie jest ten program. Dzięki za zwrócenie na to uwagi. Appimage nie chciałem.

Stwierdziłem też, że jest to dobry przyczynek do lepszego zrozumienia jak to wszystko działa. Czy na poziomie kompilacji programu, czy umieszczania go w systemie.

Po kilku nieudanych kompilacjach, próbując na chybił trafił, przeszedłem proces na podstawie PKGBUILD z Archa, skąd instalację zrobiłem tak:

Kod [Zaznacz] Rozwiń

make INSTALL_ROOT="~/qnapi/instalka" install
No ale właśnie zastanawiałem się nad takim sposobem instalacji jak piszesz. Jeśli jako root wywołuję make install, który to wrzuca mi do katalogów z systemem jakieś pliki, to skąd mam pewność, że niczego mi nie nadpisze? Przez przypadek, albo i złośliwie? Jak na ten moment rozumiem, manager pakietów zapewnia mi, że instalowany pakiet nie nadpisze plików innego pakietu. Ale tutaj takiej gwarancji nie mam?

[pavbaranov]

No ale właśnie zastanawiałem się nad takim sposobem instalacji jak piszesz. Jeśli jako root wywołuję make install, który to wrzuca mi do katalogów z systemem jakieś pliki, to skąd mam pewność, że niczego mi nie nadpisze?

Nie masz takiej pewności. Dlatego najlepszym sposobem wprowadzania do systemu jakichkolwiek programów jest zrobienie ze źródeł prawidłowej paczki (w Twoim przypadku rpm) i ich instalacja menedżerem paczek. Od lat tak robię. Drugi sposób, to instalacja całej aplikacji w /opt (trzeba przeglądnąć plik *.pro i zobaczyć, czy da się go w ten sposób zainstalować; mogę na to spojrzeć, ale po południu/wieczorem).

EDIT:
Tutaj: https://github.com/rpmsphere/source/blob/master/q/qnapi-0.2.3-1.1.src.rpm masz plik spec, który umożliwia budowę paczki QNapi dla Fedory (zresztą prawdopodobnie po lekkich zmianach dla każdej dystrybucji opartej o rpm).
Tutaj: https://fedoramagazine.org/how-rpm-packages-are-made-the-spec-file/ - instrukcja pisania plików *.spec - przydaje się.
Po zbudowaniu paczki (za moich czasów robił to bodaj rpm, a teraz chyba dnf co najmniej również) dostajesz paczkę w formacie rpm i masz pewność, że nie zrobi w systemie kuku nadpisując coś itp. itd. Nadto ogromną zaletą jest to, że taka paczka jest łatwa do zarządzania w przeciwieństwie do binarek budowanych bezpośrednio ze źródeł i w ten sposób instalowanych (czyli z pominięciem rpm). Ogólnie, to sam proces budowania paczki ze źródeł sprowadza się we wszystkich (chyba) dystrybucjach do tego samego. Otóż, na dysku zostają skompilowane ze źródeł pliki, ale ostatnia faza (np. make install), czyli instalacja nie odbywa się do systemu, a do paczki (tu rpm), którą potem można zarządzać przez menedżera paczek. Jak pisałem - gorąco polecam, bo to niemal jedyny gwarant, że w systemie nie zrobimy sobie niepotrzebnej kaszany.

[micdnj]

Trochę walki było, ale udało się zrobić pakiet.

I na zakończenie tematu zrobiłem jeszcze test. Zrobiłem drugi pakiet o innej nazwie, z tymi samymi plikami. I okazało się, że bez mrugnięcia został on zainstalowany. To zmieniłem jeden z plików, żeby nie był identyczny jak w pierwszym pakiecie, i teraz już krzyczał że jest konflikt. Także jak widać jeden plik może być dostarczony przez więcej niż jeden pakiet, z tym że musi on być w obu identyczny. Komenda dnf provides wskazuje wtedy na pierwszy z zainstalowanych pakietów.