Capitolo 2: refactor e finalizzazione

chapters/2 - Analisi.tex

@@ -6,11 +6,10 @@ \section{Requisiti}
 Il progetto si pone due principali obiettivi:
 \begin{itemize}
 	\setlength\itemsep{0.8em}
-	\item La generazione automatica di pacchetti di installazione multi-piattaforma \\ con \ac{jre} integrato
-	\item La pubblicazione automatica dei rilasci del software all'interno di repository pubblici selezionati
+	\item La generazione automatica di pacchetti di installazione multi-piattaforma \\ con \ac{jre} integrato.
+	\item La pubblicazione automatica dei rilasci del software all'interno di repository pubblici selezionati.
 \end{itemize}
-Con integrazione di un \ac{jre} si intende il supplemento di una \ac{jvm} all'interno del pacchetto di installazione.
-L'utente potrebbe non aver alcun \ac{jre} installato sul proprio dispositivo, oppure quello presente potrebbe essere obsoleto. Inserendo una macchina virtuale Java: si fornisce uno specifico ambiente di esecuzione eliminando potenziali problemi di compatibilità e si agevola la procedura di installazione per l'utente finale.
+Un pacchetto software è un insieme di risorse necessarie per eseguire un'applicazione o un servizio su un sistema. Sono usualmente distribuiti all'interno di archivi compressi contenenti meta-dati quali: nome, descrizione, versione e dipendenze, pacchetti esterni necessari all'esecuzione. La pubblicazione è l'atto di inserire il software in archivi (repository) online con l'intento di consentire l'installazione agli utenti finali. Entrambi i processi devono essere automatizzati ed integrati all'interno di una pipeline di integrazione e rilascio continua.
 
 \paragraph{Requisiti funzionali}
 
@@ -25,7 +24,7 @@ \section{Requisiti}
 
 \begin{itemize}
 	\item \textbf{Automazione dei pacchetti}: la generazione dei pacchetti di installazione deve essere automatica e configurabile
-	\item \textbf{Automazione della distribuzione}: il rilascio di una nuova versione deve essere eseguito interamente in automatico, compreso la distribuzione nei repository selezionati.
+	\item \textbf{Automazione della distribuzione}: il rilascio di una nuova versione comprende la distribuzione di essa nei repository selezionati e deve essere eseguito automaticamente.
 	\item \textbf{Verifica funzionamento}: entrambi i processi descritti precedentemente devono essere corredati da verifiche del loro funzionamento e devono bloccare la procedura di rilascio nell'eventualità siano presenti errori.
 \end{itemize}
 
@@ -132,9 +131,14 @@ \subsection{Package manager}
 
 \paragraph{Arch User Repository} Una distribuzione importante nel vasto panorama dei fork Linux è Arch. Arch è una distribuzione Linux con architettura x86-64 creata seguendo la filosofia \ac{kiss}. È infatti rinomata per essere leggera, veloce, estremamente scalabile ed adattabile alle proprie esigenze. Data la sua natura minimalista, l'installazione iniziale non incorpora alcun strumento di configurazione automatica, nessun ambiente desktop e nessun altro strumento necessario all'avvio del sistema. Il sistema di gestione dei pacchetti si chiama \textit{pacman} ed a differenza dei concorrenti, opera sia a basso che ad alto livello. Un pacchetto non è altro che un file shell script denominato \textit{PKGBUILD} contenente le istruzioni necessarie a scaricare i sorgenti e compilarli attraverso un comando: \textit{makepkg}. La linearità dei file PKGBUILD rende la creazione di pacchetti alla portata di qualsiasi utente difatti Arch supporta \textbf{\ac{aur}}, un tratto distintivo di questa distribuzione. Si tratta di un repository di pacchetti in cui qualsiasi utente, anche non sviluppatore, può contribuire.  
 
-\paragraph{Windows e winget} Nell'ambiente Windows fino a poco tempo fa non prevedeva alcun package manager ufficiale pre-installato. Solamente dal settembre 2020 è nato ``winget": package-management system open-source sviluppato da Microsoft. Supporta pacchetti di installazione EXE, MSIX e MSI. Il repository dei pacchetti è accessibile pubblicamente ed è possibile mediante richieste di contribuzione e previa approvazione, pubblicare pacchetti all'interno di esso.
+\paragraph{Windows e winget} Discorso differente vale per Windows, ove fino a poco tempo fa non era previsto alcun package manager ufficiale pre-installato. Gli utenti usualmente installano software attraverso pacchetti distribuiti in siti web ad-hoc, store non ufficiali o attraverso il Microsoft Store, gli sviluppatori invece, per sfruttare tutti i benefici della gestione a pacchetti utilizzano package-management system di terze parti. Solamente nel settembre 2020 è nato ``winget": package-management system open-source sviluppato da Microsoft, il quale supporta pacchetti di installazione EXE, MSIX e MSI. Il repository dei pacchetti è accessibile pubblicamente ed è possibile mediante richieste di contribuzione e previa approvazione, pubblicare pacchetti all'interno di esso.
 
-\paragraph{Pacchetti containerizzati} Un'altra tipologia sono i pacchetti detti containerizzati, ovvero eseguiti all'interno di ambienti separati dal sistema. Questa caratteristica fornisce due principali vantaggi: la possibilità per una applicazione di usare la propria versione desiderata di librerie di sistema senza creare conflitti e la trasparenza all'utente nell'accesso di risorse di sistema, garantendo un livello di sicurezza maggiore rispetto pacchetti gestiti normalmente.
+\paragraph{Pacchetti containerizzati} Un'altra tipologia sono i pacchetti detti containerizzati, ovvero eseguiti all'interno di ambienti separati con un accesso limitato al sistema. Questa caratteristica fornisce due principali vantaggi: la possibilità per una applicazione di usare la propria versione desiderata di librerie di sistema senza creare conflitti e la trasparenza all'utente nell'accesso alle risorse di sistema, garantendo un livello aggiuntivo di sicurezza. È il caso dei pacchetti \textit{snap}, pacchetti auto-contenuti considerati universali perché compatibili con una notevole quantità di distribuzioni Linux. Quest'ultimi sono disponibili ed installabili all'interno dello ``SnapStore", l'unico repository compatibile ed ufficiale.
 
 \paragraph{Analisi rispetto ai requisiti}
-Nell'ottica di soddisfare il requisito multi-piattaforma del progetto è necessario analizzare le piattaforme di destinazione per il simulatore. Mentre per Windows e MacOS esistono specifiche tipologie di pacchetti di installazione supportati ufficialmente, per Linux non esiste uno standard univoco. Tuttavia  i pacchetti RPM e DEB sono supportati dalla maggior parte delle distribuzioni, in particolare il primo è citato nella specifica ``Linux Standard Base". Il PKGBUILD di Arch supporta nativamente l'estrazione di sorgenti RPM e DEB, pertanto a fronte di questa analisi essi risultano la scelta più opportuna.
+Nell'ottica di soddisfare il requisito multi-piat\-ta\-for\-ma del progetto è necessario analizzare le piattaforme di destinazione elencate. Data la natura closed-source di Windows e MacOs, i due sistemi operativi non richiedono particolari attenzioni dato che le tipologie di pacchetti generabili da jpackage sono sufficienti ed ufficialmente supportati. Linux al contrario è notevolmente frammentato, ogni distribuzione è libera di utilizzare il package management system preferito o di inventare una tipologia di pacchetto completamente nuova. Purtroppo non esistono statistiche ufficiali riguardo la diffusione delle distribuzioni, molte di esse si basano su stime o utilizzano dati non attendibili. Dall'altro lato analizzando i pacchetti generabili da jpackage possiamo trarre delle conclusioni.
+\begin{itemize}
+	\item RPM significa ``RedHat Package Manager", progettato per RedHat e le distribuzioni derivate, risulta diffuso inoltre su Fedora, CentOs, OpenSUSE e tante altre distribuzioni. 
+	\item DEB è l'abbreviazione di ``Debian packages", supportato da Debian e le distribuzioni derivate. Secondo distrowatch.com Debian Linux presenta più di 400 distribuzioni derivate e più di 120 di queste sono attive.
+\end{itemize}
+È evidente come le due tipologie coprono un ampio spettro nel panorama Linux. Queste due tipologie sono inoltre supportate nativamente da PKGBUILD, il quale autonomamente estrae il loro contenuto lasciando allo sviluppatore solamente il compito di riposizionare esso nel filesystem del sistema installante. Il supporto ai pacchetti snap fornisce un ulteriore livello di compatibilità essendo di fatto considerato una tipologia universale nel mondo Linux.