Quali sono i pro / contro di deb vs. rpm?

Per qualsiasi motivo, ho sempre usato le distribuzioni basate su RPM (Fedora, Centos e attualmente openSUSE). Ho sentito spesso affermare che deb è migliore di rpm, ma quando mi è stato chiesto perché, non sono mai stato in grado di ottenere una risposta coerente (di solito invece ottengono un po 'di zelo e abbondanti quantità di sputo).

Capisco che ci possano essere alcuni motivi storici, ma per le distribuzioni moderne che utilizzano i due diversi metodi di confezionamento, qualcuno può dare i meriti tecnici (o altro) dell'uno rispetto all'altro?

La principale differenza per un manutentore del pacchetto (penso che sarebbe "sviluppatore" nel gergo Debian) è il modo in cui i metadati del pacchetto e gli script di accompagnamento si incontrano.

Nel mondo degli RPM, tutti i tuoi pacchetti (gli RPM che mantieni) si trovano in qualcosa del genere ~/rpmbuild. Sotto, c'è la SPECdirectory per i tuoi file spec, una SOURCESdirectory per i tarball di origine RPMSe le SRPMSdirectory in cui inserire gli RPM e gli SRPM appena creati e alcune altre cose che non sono rilevanti adesso.

Tutto ciò che ha a che fare con il modo in cui verrà creato l'RPM è nel file delle specifiche: quali patch verranno applicate, possibili pre e post script, metadati, log delle modifiche, tutto. Tutti i tarball di origine e tutte le patch di tutti i pacchetti sono in FONTI.

Ora, personalmente, mi piace il fatto che tutto vada nel file spec e che il file spec sia un'entità separata dal tarball sorgente, ma non sono eccessivamente entusiasta di avere tutte le fonti in SOURCES. IMHO, SOURCES si ingombra abbastanza velocemente e tendi a perdere traccia di ciò che è lì dentro. Tuttavia, le opinioni differiscono.

Per gli RPM è importante utilizzare lo stesso tarball esatto di quello rilasciato dal progetto a monte, fino al timestamp. In generale, non ci sono eccezioni a questa regola. I pacchetti Debian richiedono anche lo stesso tarball dell'upstream, sebbene la politica Debian richieda il riconfezionamento di alcuni tarball (grazie, Umang).

I pacchetti Debian hanno un approccio diverso. (Perdona qualsiasi errore qui: ho meno esperienza con i deb di quelli con gli RPM.) I file di sviluppo dei pacchetti Debian sono contenuti in una directory per pacchetto.

Quello che (penso) mi piace di questo approccio è il fatto che tutto è contenuto in una singola directory.

Nel mondo Debian, è un po 'più accettato trasportare patch in un pacchetto che non è (ancora) a monte. Nel mondo RPM (almeno tra i derivati ​​Red Hat) questo è malvisto. Vedi "FedoraProject: stare vicino ai progetti a monte" .

Inoltre, Debian ha una grande quantità di script in grado di automatizzare gran parte della creazione di un pacchetto. Ad esempio, creare un pacchetto - semplice - di un programma Python con setuptool, è semplice come creare ed eseguire un paio di file di metadati debuild. Detto questo, il file spec per tale pacchetto in formato RPM sarebbe piuttosto breve e anche nel mondo RPM ci sono molte cose automatizzate al giorno d'oggi.

Un sacco di gente confronta con l'installazione del software apt-getper rpm -i, e quindi dire DEB meglio. Questo tuttavia non ha nulla a che fare con il formato di file DEB. Il vero confronto è dpkgvs rpme aptitude/ apt-*vs zypper/ yum.

Dal punto di vista di un utente, non c'è molta differenza in questi strumenti. I formati RPM e DEB sono entrambi solo file di archivio, con alcuni metadati allegati. Sono entrambi ugualmente arcani, hanno percorsi di installazione hardcoded (schifo!) E differiscono solo per i dettagli sottili. Entrambi dpkg -ie rpm -inon hanno modo di capire come installare le dipendenze, tranne se si verificano nella riga di comando.

Oltre a questi strumenti, esiste la gestione dei repository sotto forma di apt-...o zypper/ yum. Questi strumenti scaricano repository, tengono traccia di tutti i metadati e automatizzano il download delle dipendenze. L'installazione finale di ogni singolo pacchetto viene consegnata agli strumenti di basso livello.

Per molto tempo, apt-getè stato superiore nell'elaborazione dell'enorme quantità di metadati molto velocemente mentre yumci vorrebbe un'eternità per farlo. RPM ha anche sofferto di siti come rpmfind dove si troverebbero 10+ pacchetti incompatibili per diverse distribuzioni. Aptcompletamente nascosto questo problema per i pacchetti DEB perché tutti i pacchetti sono stati installati dalla stessa fonte.

A mio avviso, zypperha davvero colmato il divario apte non c'è motivo di vergognarsi di utilizzare una distribuzione basata su RPM in questi giorni. È altrettanto utile se non più semplice da utilizzare con il servizio di build openSUSE a portata di mano per un enorme indice di pacchetti compatibili.

Dal punto di vista dell'amministratore di sistema, ho riscontrato alcune differenze minori, principalmente nel set di strumenti dpkg / rpm piuttosto che nel formato del pacchetto.

• dpkg-divertrende possibile che il proprio file sostituisca quello proveniente da un pacchetto. Può essere un vero toccasana quando hai un programma che cerca un file /usro /libche non accetta /usr/localuna risposta. L'idea è stata proposta, ma per quanto posso dire non adottata, in rpm.

• Quando ho amministrato l'ultima volta i sistemi basati su rpm (che certamente era anni fa, forse la situazione è migliorata), rpm sovrascriveva sempre i file di configurazione modificati e spostava le mie personalizzazioni in *.rpmsave(IIRC). Questo ha reso il mio sistema non avviabile almeno una volta. Dpkg mi chiede cosa fare, mantenendo le mie personalizzazioni come predefinite.

• Un pacchetto binario rpm può dichiarare dipendenze dai file piuttosto che dai pacchetti, il che consente un controllo più preciso rispetto a un pacchetto deb.

• Non è possibile installare un pacchetto rpm versione N su un sistema con la versione N-1 degli strumenti rpm. Ciò potrebbe valere anche per dpkg, tranne per il fatto che il formato non cambia così spesso.

• Il database dpkg è costituito da file di testo. Il database rpm è binario. Questo rende il database dpkg facile da investigare e riparare. D'altra parte, fino a quando nulla va storto, rpm può essere molto più veloce (l'installazione di un deb richiede la lettura di migliaia di piccoli file).

• Un pacchetto deb utilizza formati standard ( ar, tar, gzip) in modo da poter ispezionare, e in un tweak pizzico) pacchetti deb facilmente. I pacchetti Rpm non sono altrettanto amichevoli.

RPM:

• 'Standardizzato' (non che non ci sia una specifica deb)
• Utilizzato da molte diverse distribuzioni (ma i pacchetti da uno non funzionano necessariamente su un altro)
• IIRC consente dipendenze dai file, non solo dai pacchetti

DEB:

• Crescente popolarità
• Permette consigli e suggerimenti (eventualmente anche RPM più recenti lo consente)

Probabilmente la domanda più importante è il gestore dei pacchetti (dpkg vs. yum vs. aptitude ecc.) Piuttosto che il formato del pacchetto (poiché entrambi sono comparabili).

Come hanno affermato diversi rispondenti, non è tanto che un certo formato di pacchetto sia chiaramente superiore. Tecnicamente, possono essere più o meno comparabili. Dal mio punto di vista molte differenze, e perché le persone preferiscono l'una all'altra, hanno a che fare con:

• La filosofia del design originale del pacchetto e il pubblico target
• La dimensione della comunità e, per estensione, la qualità e la ricchezza dei repository

Filosofia:

Nel mondo Ubuntu / Debian / Mint / ..., gli utenti si aspettano che il pacchetto installato "funzioni" una volta installato. Ciò significa che durante l'installazione, i pacchetti dovrebbero prendersi cura di tutto il necessario per farli funzionare correttamente, incluso ma non limitato a:

• impostazione dei lavori cron necessari o opzionali
• impostazione di alternative / alias
• impostazione degli script di avvio / arresto
• compresi tutti i file di configurazione necessari con valori predefiniti che hanno senso
• mantenendo le vecchie versioni delle librerie e aggiungendo i giusti collegamenti simbolici alle librerie (.so's) per la retrocompatibilità
• supporto pulito per binari multi-arch (32 e 64 bit) sulla stessa macchina e così via.

Nel mondo degli rpm - è vero che questa era la situazione diversi anni fa, e da allora potrebbe essere migliorata - mi sono trovato a dover eseguire ulteriori passaggi (ad esempio chkconfig, abilitare i lavori cron) per far funzionare davvero i pacchetti. Questo può andare bene per amministratori di sistema o persone che sono informate su Unix, ma fa soffrire le esperienze dei principianti. Si noti che non è che il formato del pacchetto RPM stesso impedisca che ciò accada, è solo che molti pacchetti non sono di fatto "completamente fatti" dal punto di vista di un principiante.

Dimensione della comunità, partecipazione e ricchezza dei repository:

Poiché la comunità ubuntu / debian / mint / ... è più ampia, sempre più persone sono coinvolte nel software di packaging e testing. Ho trovato la ricchezza e la qualità dei repository superiori. In Ubuntu raramente, se non del tutto, ho bisogno di scaricare sorgente e compilare da esso. Quando sono passato da Red Hat a Ubuntu a casa, il tipico repository RHEL aveva ~ 3000 pacchetti, mentre allo stesso tempo, ubuntu + universo + multiverso tutti disponibili direttamente da qualsiasi mirror canonico, aveva ~ 30.000 pacchetti (circa 10x). La maggior parte dei pacchetti che stavo cercando in formato RPM non erano facilmente accessibili tramite una semplice ricerca e clic nel gestore dei pacchetti. Hanno richiesto il passaggio a repository alternativi, la ricerca nel sito web del servizio rpmfind ecc. Questo, nella maggior parte dei casi, piuttosto che risolvere il problema, ha rotto la mia installazione non riuscendo a limitare ciò che le dipendenze possono o non possono essere aggiornate correttamente. Ho colpito il fenomeno dell '"inferno delle dipendenze", come descritto sopra da Shawn J. Goff.

Al contrario in Ubuntu / Debian ho scoperto che non ho quasi mai bisogno di compilare dal sorgente. Anche a causa di:

• Il ciclo di rilascio rapido di Ubuntu (6 mesi)
• L'esistenza di PPA pienamente compatibili che funzionano immediatamente
• I repository single source (tutti ospitati da Canonical) non hanno bisogno di cercare repository alternativi / complementari
• Esperienza utente senza interruzioni da un clic all'altro

Non ho mai dovuto scendere a compromessi con le versioni precedenti dei pacchetti che mi interessavano, anche quando non erano gestite da sviluppatori ufficiali (canonici). Non ho mai dovuto lasciare il mio gestore di pacchetti GUI amichevole preferito per eseguire una comoda ricerca per parola chiave, per trovare e installare qualsiasi pacchetto desiderassi. Inoltre, alcune volte ho installato pacchetti debian (non canonici) su Ubuntu e hanno funzionato bene, nonostante questa compatibilità non sia ufficialmente garantita.

Nota che questo non ha lo scopo di iniziare una guerra di fiamme, è solo condividere la mia esperienza avendo usato entrambi i mondi in parallelo per diversi anni (lavoro vs casa).

Penso che il pregiudizio non provenga dal formato del pacchetto, ma dalle incoerenze che esistevano nei repository di RedHat.

Ai tempi in cui RedHat era una distribuzione (prima dei tempi di RHEL, Fedora e Fedora Core), le persone a volte si trovavano in "RPM Hell" o "Hell of Hell". Ciò si è verificato quando un repository sarebbe finito con un pacchetto che aveva dipendenze (di solito più strati in profondità) che si escludevano a vicenda. O si verificherebbe quando due pacchetti diversi avessero due dipendenze reciprocamente esclusive. Questo era un problema con lo stato del repository, non con il formato del pacchetto. L '"inferno RPM" ha lasciato un disgusto per i sistemi RPM tra alcuni utenti Linux che erano stati scottati dal problema.

C'è anche la differenza "filosofica" in cui nei pacchetti Debian è possibile porre domande e con ciò bloccare il processo di installazione. Il lato negativo di questo è che alcuni pacchetti bloccheranno i tuoi aggiornamenti fino a quando non risponderai. Il lato positivo di questo è, anche come differenza filosofica, sui sistemi basati su Debian, quando un pacchetto è installato, è configurato (non sempre come si desidera) e funzionante. Non su sistemi basati su Redhat in cui è necessario creare / copiare da / usr / share / doc / * un file di configurazione predefinito / modello.

Una cosa che mi piace degli RPM è l'aggiunta (recente?) Degli RPM delta. Ciò consente un aggiornamento più semplice, riducendo la larghezza di banda richiesta.

I DEB sono file ar standard (con più archivi standard all'interno), gli RPM sono file binari "proprietari". Personalmente penso che il primo sia più conveniente.

Solo due cose che posso pensare dalla cima della mia testa. Entrambi sono molto comparabili. Entrambi hanno strumenti eccellenti per l'imballaggio. Non credo che ci siano così tanti meriti l'uno sull'altro o viceversa.

OpenSUSE Build Service (OBS) e zypper sono un paio dei motivi per cui preferisco RPM su deb dal punto di vista del packager e dell'utente. Zypper ha fatto molta strada ed è piuttosto veloce. OBS, sebbene possa gestire i detriti, è davvero bello quando si tratta di impacchettare rpms per varie piattaforme come openSUSE, SLE, RHEL, centos, fedora, mandriva, ecc.

I pacchetti Debian possono includere una dimensione installata , ma non credo che gli RPM abbiano un campo equivalente. Può essere calcolato in base ai file inclusi nel pacchetto, ma non può essere fatto affidamento su azioni che possono essere eseguite negli script pre / post installazione.

Ecco un ottimo riferimento per il confronto di alcune funzionalità specifiche disponibili per ogni formato di packaging specifico: http://debian-br.sourceforge.net/txt/alien.htm (secondo il web server, quel documento è piuttosto vecchio : Ultima modifica: domenica 15 ottobre 2000, quindi questo potrebbe non essere il miglior riferimento.)

Per i pacchetti Debian esiste un ampio set di script helper, un manuale politico coerente e almeno un modo di fare quasi tutto. Le dipendenze sono gestite molto bene e possono essere definite in granularità molto buona. Ricostruire i pacchetti è molto semplice con i pacchetti debian e ben supportati dagli strumenti disponibili.

Nessuna delle altre risposte tocca come le seguenti tre differenze fondamentali abbiano conseguenze reali:

1. debi file sono fondamentalmente solo ararchivi contenenti due tarball compressi
2. debi pacchetti e il dpkgsistema memorizzano gli script del manutentore come file separati
3. dpkged rpmeseguire gli script del manutentore in un ordine diverso durante gli aggiornamenti.

Insieme, queste differenze hanno reso molto più facile per me risolvere i problemi causati da pacchetti errati e far sì che i pacchetti si comportino nel modo in cui ne ho bisogno, sui debsistemi basati su quelli basati su quelli rpm, sia come amministratore di sistema che come pacchetto .

A causa del n. 1, se devo modificare un debfile, posso semplicemente aprirlo, apportare le modifiche che desidero e riconfezionarlo, utilizzando gli strumenti standard presenti sulla maggior parte dei sistemi .

Ciò include la modifica / aggiunta / rimozione di eventuali dipendenze, o qualsiasi file del pacchetto, o uno qualsiasi degli script del manutentore, o la modifica della versione o del nome del pacchetto.

A causa del n. 2, se c'è un problema negli script "rimuovi" installati da un pacchetto che è già installato , posso ripararlo banalmente, usando strumenti standard che esistono su qualsiasi sistema .

A causa di # 3, posso fare alcune di quelle correzioni semplicemente rilasciando una nuova versione del mio pacchetto, perché durante l'aggiornamento, dpkgesegue lo script "pre-installazione" della nuova versione del pacchetto prima dello script "post-rimozione" di la vecchia versione.

Ciò significa che la superficie di violare la "principio recuperabilità" è più piccolo di debpacchetti: più errori in una versione precedente del pacchetto possono essere recuperati da una nuova versione.

E dal momento che modificare il pacchetto è così semplice - l'attuale sovraccarico specifico per il pacchetto e le conoscenze generali sono minuscole - è accessibile a più persone e richiede meno tempo e fatica, con i debfile.