Perché non esiste un gestore di pacchetti veramente unificato per Linux?

Perché non c'è un gestore di pacchetto unificato che funge da interfaccia tra l'utente finale e sottostante gestore di pacchetti di basso livello ( apt, yast, pacman, ecc)?

È difficile da fare e quindi non pratico, oppure esiste un vero ostacolo che lo rende impossibile?

Prima di tutto, c'è. Il problema non è che non esiste un gestore pacchetti unificato, il problema è che ce ne sono dieci, sul serio.

Prendiamo il mio preferito: poldek. È un front-end utente per la gestione dei pacchetti che può essere eseguito su diverse distribuzioni e gestire uno rpmo due debpacchetti. Poldek non fa ciò che fa rpm (lo lascia a rpm) e invia semplicemente i comandi giusti senza che l'utente debba capire tutto quel casino.

Ma i problemi non finiscono qui. Ognuno ha un'idea diversa di come dovrebbe apparire un front-end utente e come dovrebbe funzionare e quali opzioni dovrebbe esporre. Quindi altre persone hanno scritto il loro. In realtà molti dei gestori di front-end del pacchetto che le persone usano oggi nelle distribuzioni comuni sono in grado di gestire più di un back-end.

Alla fine, tuttavia, il problema (o il vantaggio) è che alle persone piacciono le cose per funzionare esattamente come vogliono, non in una meta-moda che cerca di soddisfare tutti solo per non riuscire a rendere davvero felice qualcuno. Questo è il motivo per cui abbiamo innumerevoli distro di gazillion in primo luogo. È la ragione per cui abbiamo così tanti ambienti desktop e gestori di finestre diversi (e il fatto che si tratti in realtà di diversi tipi di cose).

Ci sono ancora proposte eccezionali su come scrivere pacchetti universali o avere un manager che li capisca tutti o che abbia un API per convertirli l'uno nell'altro ... ma alla fine Unix è il migliore se usato secondo la sua filosofia ... ogni strumento fa una cosa e la fa bene .

Ogni volta che hai uno strumento che cerca di fare più di una cosa, finisce per non essere altrettanto bravo in una di esse. Ad esempio, fa poldekschifo nella gestione delle dipendenze del pacchetto deb.

In breve: perché ogni distribuzione utilizza un approccio diverso alla gestione dei pacchetti. Semplicemente non sono compatibili. La strategia di gestione che funziona meglio per Ubuntu avrà poco senso su Arch, ecc. Un gestore di pacchetti "universale" (indipendente dalla distribuzione) sarebbe solo un ulteriore livello di interfaccia utente, che non funzionerebbe mai come il gestore specifico di ogni distribuzione.

Quindi, usando le tue parole, è difficile da fare e quindi non pratico , anche perché quasi nessuno ne trarrebbe beneficio.

Ragioni storiche, principalmente. Diversi sistemi di gestione dei pacchetti sono stati istituiti nello stesso periodo, in particolare .rpm e .deb. Ognuno ha i suoi aderenti e ognuno è abbastanza buono che nessun singolo gestore di pacchetti ha un vantaggio convincente. I distributori certamente non vedranno il punto in una ricostruzione radicale del loro sistema per implementare un gestore di pacchetti diverso.

Ciò richiederebbe anche la ricostruzione di ciascun pacchetto all'interno del sistema (10.000 nel caso di debian). Richiederebbe inoltre l'implementazione di un sistema di migrazione regolare in modo che gli utenti del sistema potessero passare dal vecchio al nuovo gestore pacchetti. Lo sforzo per migrare sarebbe incredibilmente grande ed esponenzialmente più grande per testare la migrazione, quindi quasi sicuramente otterresti molte rotture. Ciò genererebbe molti scommettitori irati.

Ogni distro mantiene il proprio set di dipendenze basato su ciò che è stato creato per quella versione. Un repository di pacchetti universale sarà troppo difficile da coordinare tra le distribuzioni poiché quasi sicuramente sorgeranno conflitti di dipendenza. Pertanto, l'effettivo vantaggio di un sistema unificato di gestione dei pacchetti (pacchetti universali) sarà impossibile da realizzare in pratica comunque.

Infine, chi può scegliere il gestore pacchetti standard universale? Il fumetto XKCD a cui si fa riferimento nei commenti sull'OP riassume la solita modalità di fallimento in questo tipo di esercizio. La standardizzazione di questo genere di cose sarebbe molto politica e probabilmente risulterebbe in qualcosa di non utilizzabile, o così profondamente imperfetto da generare un altro giro di manipolazione degli standard - se le parti possono raggiungere un accordo.

Quindi, in sostanza, si riduce a: troppo politico, troppo duro, troppo rischioso e nessun beneficio per realizzarlo.

Quello che hai descritto,

che funge da interfaccia tra l'utente finale e il gestore di pacchetti a bassa leva sottostante

suona un po 'come PackageKit per me, che è ,

PackageKit è un sistema progettato per facilitare l'installazione e l'aggiornamento del software sul computer. L'obiettivo principale del progetto è unificare tutti gli strumenti grafici del software utilizzati in diverse distribuzioni e utilizzare alcune delle più recenti tecnologie come PolicyKit per ridurre il processo.

Modifica: vedi qui per un elenco di backend supportati. Edit2: rimossa osservazione inutile.

Innanzitutto, capisci che "Linux" non è un sistema operativo. È un kernel. Un gestore di pacchetti è un concetto a livello di sistema operativo, non a livello di kernel. Pertanto, chiedere un gestore di pacchetti unificato per Linux non è davvero sensato.

Tuttavia, se ti stai chiedendo perché i vari sistemi operativi che usano il kernel Linux non hanno gestori di pacchetti compatibili, puoi anche chiederti perché Windows e Mac non hanno gestori di pacchetti compatibili. O altri due sistemi operativi.

Diversi sistemi operativi soddisfano le esigenze dei diversi utenti e il gestore dei pacchetti ne fa parte. Perché tutte le distribuzioni Linux non hanno lo stesso gestore di finestre? O vieni con lo stesso software preinstallato?

Risposta: colpi diversi per persone diverse.