Non ho sviluppato alcuna applicazione di produzione per il SO Linux. Ci sono un paio di cose che mi infastidiscono:
Che cosa fanno le persone per gestire tutte queste differenze? C'è un modo per astrarre da queste differenze? (A proposito, mi manca qualcosa?)
Naturalmente ti mancano alcune possibilità - la maledizione e la benedizione del software open source è che chiunque può creare la propria alternativa, e molti lo fanno - ma hai elencato le piattaforme e i formati di distribuzione più importanti.
Quindi cosa fai per essere il più compatibile possibile? Ci sono due ampie opzioni. Il primo è quello di distribuire il codice sorgente con le istruzioni di compilazione. Ciò significa che non devi affrontare nulla di tutto ciò, ma tutti coloro che vogliono usare il tuo software devono compilarsi. Questo è facile in linea di principio, ma in pratica equivale al presupposto che i tuoi utenti abbiano esattamente lo stesso set-up o che apprendano come ottenere e compilare tutte le dipendenze necessarie nelle versioni corrette. Ciò diventa sempre più difficile, più il tuo software è complesso, e comunque molti, molti utenti, anche di Linux, rifuggono dalla compilazione delle cose stesse perché lo considerano di basso livello e difficile.
L'altro è diventare una delle librerie. Ciò significa aderire ad alcune convenzioni di packaging e duplicare un po 'di lavoro, sia per conformarsi a diversi formati di packaging, sia per rimanere aggiornato per ogni nuova versione del SO, ma significa che qualsiasi utente potenziale deve solo cercare il (auspicabilmente, memorabile e informativo) nome del software nel gestore pacchetti e fare clic su "sì". Se vuoi un qualsiasi tipo di penetrazione nel mercato non geek, questa è la strada da percorrere.
Devo aggiungere che ci sono (ovviamente) innumerevoli varianti e strategie miste che puoi seguire. Ad esempio, puoi mirare a diventare un pacchetto non ufficiale . Ciò significa che speri che a qualcun altro piaccia il tuo software abbastanza da installarlo e che crei un pacchetto RPM o APT e lo condivida con altri (ovviamente puoi incoraggiarlo o addirittura aiutarlo con questo se vuoi). Ciò significa che gli utenti di terze parti devono solo registrare un repository aggiuntivo, cercare il tuo software e quindi fare clic su "sì". I trade-off sono esattamente come ti aspetteresti: devi ancora farlo più volte, e il risultato funziona solo per un obiettivo specifico, ma la maggior parte del lavoro viene eseguita da qualcun altro.
Lo facciamo al lavoro. Non vogliamo distribuire il codice sorgente, quindi le distribuzioni solo binarie sono l'unica scelta. La nostra soluzione a questo problema di versione della libreria condivisa è di collegare la maggior parte delle librerie in modo statico. (Eccezione: libc è collegato in modo dinamico.) È possibile specificare una singola libreria come /full/path/to/library.a . Si noti che l'ordine di collegamento delle librerie statiche è più importante dell'ordine di collegamento delle librerie dinamiche. Si noti inoltre che la libreria / full / path / to può differire tra varie distribuzioni. Il percorso completo nel nostro caso è un'opzione configurabile nei makefile (non usiamo gli autotools GNU per molte buone ragioni). Inoltre, nota che CentOS, RHEL e Fedora non offrono librerie linkabili staticamente, a causa della opinione di Ulrich Drepper . Quindi, la macchina di compilazione non può usare un sistema operativo in questa lista. Ovviamente, i binari compilati possono essere eseguiti su CentOS, RHEL e Fedora.
Il problema .deb vs .rpm è risolto usando tar.gz come pacchetto di distribuzione. Basta decomprimerlo in una directory in cui si desiderano i binari e quindi avviare il programma. Tutte le librerie nel nostro caso sono collegate staticamente, quindi non ci sono file .so nel nostro pacchetto di distribuzione. Pertanto, la variabile d'ambiente LD_LIBRARY_PATH non è necessaria.
La nostra interfaccia utente grafica non è in realtà costruita né su GTK né su QT. Usa Java. Questo è un approccio che può essere preso in considerazione anche per altre applicazioni. Il vantaggio di Java è che la GUI può essere eseguita anche su macchine Windows.
Se vuoi creare un'applicazione GUI e non c'è un motivo particolare per usare C o C ++ come lingua, ti consiglio di prendere in seria considerazione alcuni linguaggi basati su JVM. Ciò significa che la tua applicazione è utile anche su Windows. Nel nostro caso, abbiamo bisogno di processare pacchetti di rete grezzi ad alte prestazioni usando socket grezzi nel programma principale, quindi deve essere implementato usando C (o C ++). Ma la GUI è un'applicazione Java separata.
Inoltre, alcune persone in questi giorni implementano GUI utilizzando linguaggi come Python. Questa è un'opzione che vale la pena considerare. Né Python né Java sono danneggiati dalla corruzione della memoria a causa dell'uso non valido del puntatore, quindi in questo senso sono chiaramente superiori a C e C ++. Tuttavia, tieni presente che l'uso di Python significa che devi spedire il codice sorgente.
different distros have different set of libraries, + Debian vs RPM packages
Conosci le tue "dipendenze di superficie". Quindi per ogni distro è necessario trovare i pacchetti che forniscono tali dipendenze (e documentano ciò), e verificare che porti anche tutte le dipendenze transitive (non solo in termini di librerie sottostanti, ma anche in termini di "costruito con le opzioni giuste" o qualsiasi vincolo di runtime potrebbe esistere). Trovare il set di pacchetti è un'attività che non è mai troppo complicata, ma dovrai testare almeno per ogni versione, quindi è necessario un buon setup di test (buona automazione e / o goot team QA).
Ma se hai un insieme complesso di dipendenze, diventa più probabile che ti imbatti in vincoli complessi su quale versione di ciò che è necessario, e a volte devi abbandonare alcune versioni di alcune distro ... o iniziare ad affrontare questo provando cose più difficili che portano un altro insieme di complessità: compilati e spedisci i tuoi glibc e le tue librerie, o costruisci binari collegati staticamente , ma aprirai una nuova lattina di worm ... Questo dipenderà strongmente su ciò che usi per creare la tua applicazione . Se si usa C ++, ad esempio, si devono prendere in considerazione molti altri dettagli (l'ABI del compilatore di sistema, l'ABI del kernel ...). Dall'esperienza, la cosa più terribile è quando usi diverse librerie commerciali, ognuna delle quali ha il proprio set di "piattaforme" supportate, e se guardi più da vicino scopri che incorrono in strane restrizioni su quale versione del compilatore puoi usare, e tu devo chiamarli e negoziare le build personalizzate ... (quell'esperienza era 15 anni fa, forse le cose vanno meglio ora).
Docker può aiutare a semplificare l'infrastruttura necessaria per i test. Può anche permetterti di saltare tutto questo, se preferisci rimanere con una distro, e spedire la tua app con un'immagine docker che si basa su quella distro (che funzionerà allo stesso modo in tutte le distro). Alcuni sistemi sul lato server lo fanno, ma non ho visto quella seconda opzione in natura per le applicazioni desktop, quindi sono sicuro che ci sono altre difficoltà (supponendo: la visualizzazione di materiale non deve essere troppo complicata se puoi passare $DISPLAY e le impostazioni di rete lo consentono, ma il lavoro di copia-incolla dovrebbe essere eseguito? Drag-and-drop? ...).
Ovviamente se ciò che costruisci è open source, meglio abbracciare ciascun sistema di distribuzione e diventare parte dell'ecosistema, come descritto nella risposta di Kilian.
Different UI - Gnome vs KDE
Nota laterale: ogni ambiente desktop (DE) viene fornito con il proprio set di pacchetti e alcune delle dipendenze potrebbero dipendere da pacchetti disponibili solo con un DE. Ma di solito qualsiasi pacchetto di cui hai bisogno è disponibile per l'installazione, quindi diciamo che questo è indirizzato dalla sezione "pacchetti distro")
Per aspetto e aspetto, se vuoi che la tua app appaia "nativa", dipende ancora da ciò che usi. Il tuo toolkit UI potrebbe essere basato su GTK, o Qt (ci sono Qt look-and-feel che possono sembrare app GTK - questo dipende anche dalla distribuzione e dai pacchetti, ma per alcune distro comuni potrebbe valer la pena documentare "installazione pacchetto così e così, vai lì nelle tue impostazioni, scegli questo ... ").
Oppure potresti usare un toolkit "neutrale" e non ti interessa. Ma avresti ancora "problemi di integrazione desktop" come " Come posso aprire la pagina web con il browser predefinito dell'utente? " o " Apri il file pdf con il visualizzatore PDF predefinito ". Esistono comandi specifici per gnome e specifici per KDE, ma ci sono anche strumenti generici, io consiglierei xdg-open . Potresti imbatterti in casi edge divertenti, quindi potresti voler offrire all'utente la possibilità di configurare i comandi di sistema per l'integrazione desktop, ma con una solida configurazione di base che dovrebbe funzionare con impostazioni del 99% (vedi < strong> XDG standard e xdg-open )
Due approcci alle librerie e amp; i problemi dell'interfaccia utente:
Per quanto riguarda il packaging e la distribuzione delle cose, è necessario raggruppare il software in più modi e organizzare la distribuzione nel modo appropriato (s) - utilizzare lo scripting o Jenkins in un accordo master / slave per questo .
Devi anche affrontare il test su più piattaforme Linux - strumenti come Docker e Travis sono i tuoi amici in questo senso .
Leggi altre domande sui tag linux linux-development