

[1] STRUTTURA DI UN PACCHETTO
=============================

Un pacchetto "Bad Penguin" puo' essere SOLO in formato .tgz
Il formato .tar.bz2 e' stato testato ma oltre ad essere piu' lento 
da installare (in media del 30%) richiede MOLTE risorse di memoria
in piu', questo lo rende inutilizzabile durante la fase d'installazione
della distribuzione. Nonostante cio', il formato bzip2, risulta una valida
alternativa nella distribuzione via internet dei pacchetti, 
in quanto riesce a comprimere dal 10% al 25% in piu' rispetto al gzip.

NOVITA': Molti mi hanno chiesto di cambiare l'estensione .tgz, che fa 
sembrare il pacchetto alla stregua della Slackware, in 
formato .bpp ( Bad Penguin Package). Questi "estetici" sono 
stati accontentati :-)

Il pacchetto viene di solito assemblato all'interno della directory
/pkg-build che corrisponde alla root ( '/' ) directory dello stesso.
Per far cio' si utilizza lo script "package-builder"
Al suo interno, oltre ai file del programma abbiamo due directory
speciali: ./install e ./incoming. 'install' contiene gli script
e le informazioni d'installazione, mentre 'incoming' contiene dei
file che vengono trattati in modo speciale.

Infatti, durante la fase d'installazione, i file presenti nella directory
./incoming vengono installati SOLO SE NON ESISTENTI. Questo e' molto
utile per fornire file di configurazione di default nella directory /etc
senza sovrascrivere quelli esistenti. 
Secondariamente, possono essere messe qui delle librerie dinamiche 
strettamente necessarie al sistema, in questo modo e' possibile 
installarle senza inchiodare la macchina (... se siete root potete 
sovrascrivere la libc mentre e' in uso !)

Nella directory ./install, invece, sono presenti i seguenti script 
d'installazione (opzionali) :

    doisnt.sh     ; da non usare (solo per compatibilita' con Slackware)
    
    PRE-INSTALL   ; eseguito prima di estrarre l'archivio
    INSTALL       ; eseguito dopo l'estrazione dell'archiov
    POST-INSTALL  ; eseguito al boot della macchina quando 'root' si collega
    X-POST-INSTALL; come POST-INSTALL ma viene eseguito quando parte x-window.
                  ; Al momento serve solo per installazione dei fonts.

    PRE-REMOVE    ; eseguito prima di rimuovere il pacchetto
		    PRE-DELETE e deprecato
    VITAL         ; se presente i file contenuti all'interno del 
                  ; MANIFEST del pacchetto non vengono rimossi
    REMOVE        ; eseguito dopo la rimozione
		    DELETE e deprecato
    POST-REMOVE   ; come REMOVE
		    POST-DELETE e deprecato
    PURGE	  ; oltre a eseguire questo script, dopo 
                  ; il POST-REMOVE, viene rimosso tutto del pacchetto,
		  ; anche i file in ./incoming (--purge)
		    PRUNE e deprecato
	
    REQUEST       ; contiene le dipendenze dai file o dai pacchetti
                  ; (E CONSIGLIATO COSTRUIRE QUESTO FILE)
		  
    CONFLICTS     ; contiene l'elenco dei pacchetti che vanno in conflitto
                    con questo, e che devono esssere rimossi prima di
		    installarlo
		    
    MANIFEST      ; Contiene la lista dei file che il pacchetto installa
                  ; non deve essere creato dall'utente, viene generato
                  ; automaticamente da 'buildTGZ' in fase di preparazione,
                  ; oppure da 'setup in fase d'installazione

    COMPILE	  ; Script utilizzato per compilare il pacchetto
    NOTES         ; Notes sulla compilazione del programma
    MD5SUM        ; Contiene le chiavi MD5 dei binari del pacchetto
    
    INFO	  ; Contiene tutte le variabili, elencate sotto nella
		  ; forma VARIABILE="VALORE"
			
Ed ecco le variabili processate all'interno del file INFO. I parametri
'BUILDTIME' e 'DISKUSAGE' sono compilati automaticamente dal
programma 'package-builder'.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  DISTRIBUTION - La distribuzione (nome+versione) su cui e' stato costruito il
                 pacchetto

  URL          - L'Home Page del pacchetto
  FTPURL       - Il sito ftp da dove si e' preso il pacchetto
  OS           - Il sistema operativo
  BUILDHOST    - La macchina su cui e' stato ostruito il pacchetto
  BUILDTIME    - Data in cui e' stato assemblato il pacchetto
  BPPVERSION   - Versione del package-builder utilizzata

Tutti questi campi, tranne DESCRIPTION, possono essere lunghi al massimo 1
(una) linea e non devono includere segni di newline.



Il file REQUEST e le dipendenze
-------------------------------
Il file REQUEST contiene una o piu' linee sulle dipendeze del pacchetto.
Ed e' nel seguente formato:
    category_name <tab> package_name <tab> [library_name]

Esempio:
	base	svgalib
orppure
	base	svgalib	libvga.so.1.2.13

Il nome della categoria rappresenta la categoria in cui e' incluso
il pacchetto. Il nome del pacchetto non deve essere necessariamente
completo (*1). Il nome (*2) della libreria deve essere la libreria da cui dipende
il programma e di cui necessita' il pacchetto.

Quando il pachetto viene installato, se il pacchetto dipendente 
si trova gia' sul sistema non ci sono problemi, altrimenti il
pacchetto dipendente viene schedulato per l'installazione solo 
se NON e' presente la libreria 
(opzionale) specificata.

L'implicazione maggiore di questa feature e' la possibilita' di installare
pacchetti di terze parti (.rpm o .deb) sensa doversi preoccupare che questi
possano rompere le dipendenze.

(*1) ESEMPIO: se si specifica come nome pacchetto
     libc-shared-6 invece di libc-shared-6.2.0.6.7
     il pacchetto non verra installato se e' installata 
     almeno una libreria glibc.

(*2) ESEMPIO: invece di specificare il nome corto (libc.so.6)
     va messo il 'soname' completo della libreria (glibc-2.0.7pre6)
     presente sul sistema omettendo il percorso.



[2] Descrizione del programma di setup
======================================

L'installazione di un pacchetto avviene tramite il comando "setup".
Se tale comando viene lanciato passando come parametro il solo nome
del pacchetto da installare, viene sottointesa la volonta' dell'utente
di effettura un'installazione in modalita' interattiva. In questa 
modalita' i pacchetti vengono installati 1 per volta sul filesystem 
di root.

Il programma "setup" fa da front-end a tutti gli altri script, suddivisi
cosi' per comodita'. Oltre ad effetturare il controllo dei parametri si
preoccupa di stabilire la modalita' di funzionamento del programma, che puo'
essere una delle seguenti :
	INSTALL  - installazione di un nuovo pacchetto;
	UPDATE   - aggiornamento di un pacchetto installato;
	RESTORE  - ripristina di un pacchetto installato;
	REMOVE   - rimozione di un pacchetto installato;
	PURGE    - rimozione completa di tutto il pacchetto;
	CHECK    - controlla se un pacchetto e' correttamente installato;
	FINALIZE - analisi e flush della coda delle dipendenze;
	POST     - flush degli script di configurazione POST-INSTALL;
	XPOST	 - flush degli script di configurazione X-POST-INSTALL;
	UPGRADE  - controlla sul disco tutti i pacchetti installati ed installa
		   da cdrom tutte le versioni aggiornate;



SETUP
-----
- Controllo dei parametri
- Posiziona il Current Directory sul mount point del filesystem di destinazione
- Pulizia scorie (install, incoming, etc.)



CHECK
-----
Permette di controllare la corretta installazione di un pacchetto:
  - controlla se il pacchetto e' installato ;
  - controlla la presenza dei file elencati in MANIFEST
  - controllati la presenza dei file dir ./incoming, 
	ovviamente rimuovendo tale prefisso, vengono invece
	scartati i file della dirs ./install
  - se tutti i file del pacchetto sono stati cancellati il pacchetto
	viene deregistrato (bello vero ?) :-)
  - visualizza il risultato dell'operazione
TODO: Controllo
TODO: Controllo
TODO: Controllo
TODO: Controllo
TODO: Controllo
TODO: Controllo
TODO: Controllo
TODO: Controllo
TODO: Controllo
TODO: Controllo
TOD tramite setup



FINALIZE
--------  
Questo poteva essere fatto da install, ma in questo modo le dipendenze
vengono elaborate tutte in una volta, evitando inutili ricorsioni.
Infatti:
- Controlla la coda delle dipendeze, se non sono soddisfatte vengono
  inserite nella coda dei paccheti da installare
- Elabora la coda dei file mancanti, prova ad installarli dalla directory
  specificata come primo parametro, se non viene passato nessun parametro
  assume l'installazione da /cdrom
- Se e' stato installato almeno 1 pacchetto ri-analizza la coda delle 
  dipendenze
- Infine, esegue il post-install se lanciato in maniera interattiva

Come vengono elaborate le dipendenze ?
- Il file /var/spool/badpenguin/DEPENDENCIES viene spostato con un altro nome
  per impedire ricorsioni
- Dal file delle dipendenze spostato viene letta la tripla
  ( categoria, pacchetto, libreria )
- Se e' stata specificata una libreria viene cercata nelle directory
  standard delle librerie, se esiste la dipendenza e' risolta
- Ovviamente, anche se il pacchetto e' gia' installato la dipendenza
  viene risolta
- I pacchetti non risolti da installare sono schedulati in /var/spool/badpenguin



INSTALL
-------

Quando si richiede l'installazione di un pacchetto setup effettua le seguenti 
operazioni:
- Decomprime il pacchetto da .tar.gz, da dove si trova, in / come .tar
  in modo da poter effettuare velocemente tutte le operazioni
- Estrae le informazioni dal pacchetto ( directory ./install )
- Aggiusta il file ./install/INFO se nel vecchio formato
- Ricava il nome del pacchetto
- (TODO) Controlla l'architettura del pacchetto
- Controlla se il pacchetto e' gia' instalato o meno
- Controlla lo spazio occupato e lo spazio residuo
- Rimuove, solo per INSTALL, pachetti in conflitto
- Visualizza il nome e la descrizione del pacchetto
- Eventualmente esegue PRE-INSTALL
- Se non presente genera il file MANIFEST
- Eslode il pacchetto sotto la root 
- Scrive i file in ./incoming solo se non presenti nel sistema
- Esegue ldconfig se l'installazione e' interattiva
- Esegue gli script doinst.sh e/o INSTALL
- Schedula per l'esecuzione eventuali file di POST-INSTALL o X-POST-INSTALL
- Schedula le dipendenze
- Schedula un eventuale riscrittura dei menu' del Window Manager
- Registra il pacchetto e sposta i file da ./install nel db dei pacchetti
- Rimuove i file temporanei
- Se interattivo esegue FINALIZE che a sua volta esegue POST-INSTALL  



POST ed XPOST
--------------
Esegue gli scipt di post-install schedulati in /var/spool/badpenguin
Quando si installa un pacchetto, lo script /install/POST-INSTALL viene copiato
in $TARGET/var/spool/badpenguin, come $NOMEPACCHETTO.post-install ed eseguito 
al riavvio della macchina.
Questo avviene mettendo 'setup --post-install' nello 
script '/etc/init.d/local.rc'



REMOVE
------
La rimozione del pacchetto passa attraverso i seguenti passi:
  - controlla se il pacchetto e' installato
  - viene eseguito lo script PRE-REMOVE
 e/o PRE-DELETE
  - se e' stato specificato PURGE allora vengo rimossi tutti i file del
    pacchetto, anche quelli specificati in ./incoming
    altrimenti vengono rimossi solo i file normali del pacchetto
    oppure, se presente il file VITAL nessun file viene rimosso.
    Attenzione: --purge ignora l'uso di VITAL (sia chiaro).
  - Esegue lo script REMOVE
 e/o DELETE
  - Esegue lo script POST-REMOVE
 e/o POST-DELETE
    (...TODO...) Questi sono da schedulare !!!
  - In caso di --purge esegue lo script PURGE e/o PRUNE
  - De-registra il pacchetto dalla directory di spool



RESTORE
-------
A differenza di install si limita SOLO a copiare i file del pacchetto che
non sono piu' presenti nel file system.


UPDATE
------
A differenza di INSTALL non fa due cose:
  - eliminare pacchetti in conflitto;
  - sovrascrivere i file (si limita a fare il restore);
invece, a differenza di RESTORE, esegue gli scipt d'installazione.



UPGRADE
-------
(...TODO...) Controlla tutti i pacchetti installati e verifica se sulla
distribuzione ne esiste una versione aggiornata, in tal caso la installa.
(...TODO...) Non implementa ancora il MAJOR,MINOR



[3] Nomi dei pacchetti
======================

I pacchetti sono nella forma <nome_pacchetto>_<versione>.bpp
Esempio: pppd_2.3.9.bpp

Per le librerie ed i pacchetti complessi va aggiunto al nome della libreria
o dell'programma i seguenti suffissi.
	-shared	per le librerie dinamiche
	-devel	per gli headers + librerie statiche (se ci sono)
	-static	per le sole librerie statiche
	-headers	per i soli headers
	-doc		per la documentazione generale
	-info		per le sole pagine info
	-bin		se ci sono solo i binari (ed ha senso indicarlo)

Quindi per le libc6 abbiamo ad esempio:
	libc6-shared_2.0.7pre6.bpp
	libc6-info_2.0.7pre6.bpp
	libc6-devel_2.0.7pre6.bpp


EOF