Uno dei tool Linux più usati al mondo è certamente APT (Advanced Packaging Tool) il package manager a linea di comando incluso sia in Debian che in Ubuntu. Tool storico, presente ormai da diverso tempo su Linux. Non c’è utente Debian o Ubuntu che non abbia mai usato apt-get.

Ora stando a quanto dice Eugene V. Lyubimkin, uno degli sviluppatori di APT, questo progetto non è manutenuto. Questo in termini pratici significa che APT non supporterà nuove funzionalità, e inoltre i bug pendenti potrebbero non essere risolti.

Morto un tool se ne elegge un altro. Quale? Bella domanda. Scegliere il successore di APT non potrebbe essere proprio immediato, e neanche tanto semplice.

In questi giorni si sta iniziando a discutere proprio del successore di APT. Non lo si sta facendo proprio apertamente in una mailing list, siamo ancora nella fase in cui i contendenti iniziano a farsi avanti.

Orbene, quali sono le possibili alternative? Al momento abbiamo due tool: CUPT e APT2. Entrambi accomunati dall’obiettivo di convivere coi tool già a bordo di Debian e Ubuntu, quindi apt-get, apt-cache, aptitude,…

Sia CUPT che APT2 intendono svolgere lo stesso ruolo di APT ovvero quello di front-end per dpkg. Infatti APT non gestisce i singoli pacchetti ma si fa solo carico di scaricarli, di esaminare le dipendenze, individuare errori e altro ancora. Il lavoro sporco viene svolto da dpkg, che provvede all’installazione, rimozione e query dei singoli pacchetti. Si può dire che “apt sta a dpkg così come yum sta ad rpm”.

Detto questo sia APT2 che CUPT intendono essere prodotti nuovi, riscritti da zero, facilmente configurabili per quanto riguarda l’impostazione dei file e indici di ricerca dei pacchetti (meta-index, package-index, source-index, file-index). Altra caratteristica interessante e comune a questi due prodotti è il fatto che entrambi vogliono essere facilmente estendibili. Questo ad esempio per venire incontro alla esigenza di uno sviluppatore che potrebbe necessitare di un plugin specifico per il download dei pacchetti (Torrent?), oppure di un sistema di cifratura diverso da quello standard.

Oltre a questo, poi, entrambi i prodotti intendono rendersi integrabili con i cosiddetti “Package Manager di Terzo Livello”. Conoscete ad esempio PackageKit? Questo è un packager manager di terzo livello. Esso è un sorta di gestore dei pacchetti universale che vuole funzionare sia su Fedora, quindi con yum/rpm, che su Ubuntu, quindi con apt2/dpkg o cupt/dpkg. Bene, proprio PackageKit sembra funzioni bene su Fedora e non funzioni su Debian. Motivo in più per sostituire APT?

A questo punto viene da chiedersi in cosa differiscono CUPT e APT2. CUPT è scritto in Perl. APT2 è scritto in Vala, un linguaggio basato su GObject i cui sorgenti vengono prima tradotti in C e poi compilati. Differenza non banale, che da un lato preclude a CUPT l’utilizzo su distribuzioni derivate da Debian che non supportano Perl (vedete Emdebian), e dall’altro appesantisce APT2 di una serie di dipendenze (glib, gobject,…) non sempre presenti su tutte le architetture e non sempre di piccole dimensioni. Perl contro C?

La strada per decidere il successore di APT è ancora lunga, e forse non proprio agevole. Non sarà semplice decidere chi rimpiazzerà APT, e sicuramente per un bel po’ di tempo continueremo ad usare questo tool. E non è neanche escluso un revival del progetto APT, una risurrezione dalle ceneri.