it-swarm.it

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?

173
Evan

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 RPM, tutti i tuoi pacchetti (gli RPM che mantieni) si trovano in qualcosa come ~/rpmbuild. Sotto, c'è la directory SPEC per i tuoi file spec, una directory SOURCES per i tarball di origine, le directory RPMS e SRPMS per inserire gli RPM appena creati e SRPM in, e alcune altre cose che non sono rilevanti ora.

Tutto che ha a che fare con il modo in cui verrà creato l'RPM si trova nel file spec: 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 di origine, ma non sono eccessivamente entusiasta di avere tutte le fonti in FONTI. IMHO, SOURCES si ingombra abbastanza velocemente e tendi a perdere traccia di ciò che è lì dentro. Tuttavia, le opinioni differiscono.

Per gli RPM è importante usare 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 setuptool'ed Python, è semplice come creare un paio di file di metadati ed eseguire 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.

87
wzzrd

Molte persone confrontano l'installazione del software con apt-get per rpm -i e quindi dire DEB meglio. Questo tuttavia non ha nulla a che fare con il formato di file DEB. Il vero confronto è dpkg vs rpm e 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. Tutti e due dpkg -i e rpm -i non ha 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 yum avrebbe impiegato secoli per farlo. RPM ha anche sofferto di siti come rpmfind dove si troverebbero 10+ pacchetti incompatibili per diverse distribuzioni. Apt ha completamente nascosto questo problema per i pacchetti DEB perché tutti i pacchetti sono stati installati dalla stessa fonte.

A mio avviso, zypper ha davvero colmato il divario con apt e 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 compatibile.

97
vdboor

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-divert rende possibile che il tuo file sostituisca quello proveniente da un pacchetto. Può essere un vero toccasana quando hai un programma che cerca un file in /usr o /lib e non accetta /usr/local per una 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 facilmente i pacchetti deb. 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).

19
Maciej Piechotka

Come hanno affermato diversi rispondenti, non è tanto che un certo formato 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
  • creazione 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 ritrovato a dover eseguire ulteriori passaggi (ad es. Chkconfig, abilitare i lavori cron) per far funzionare davvero i pacchetti. Questo può essere ok 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 "completati" da la prospettiva 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 in esso, 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, anziché risolvere il problema, ha interrotto la mia installazione non riuscendo a limitare le dipendenze che 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 gestiti 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).

15
arielf

Penso che la distorsione 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 delle dipendenze (di solito più strati di 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. "RPM Hell" ha lasciato un disgusto per i sistemi RPM tra alcune popolazioni di utenti Linux che erano stati scottati dal problema.

12
Shawn J. Goff

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.

8
Luc Stepniewski

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.

6
johansson

I pacchetti Debian possono includere 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: Dom, 15 Ott 2000 , quindi questo potrebbe non essere il miglior riferimento.)

5
Mike Gray

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 sia in grado di gestire i deb, è davvero bello quando si tratta di impacchettare rpms per varie piattaforme come openSUSE, SLE, RHEL, centos, Fedora, mandriva, ecc.

5
decriptor

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

  1. I file deb sono praticamente solo ar archivi contenenti due tarball compressi
  2. I pacchetti deb e il sistema dpkg memorizzano gli script del manutentore come file separati
  3. dpkg e rpm eseguono gli script del manutentore in un ordine diverso durante gli aggiornamenti.

Insieme, queste differenze hanno reso molto più semplice per me risolvere i problemi causati da pacchetti difettosi e far sì che i pacchetti si comportino nel modo in cui ne ho bisogno, su sistemi basati su deb che su rpm sistemi basati, entrambi come amministratore di sistema e come pacchetto.

A causa del n. 1, se devo modificare un file deb, posso aprirlo banalmente, fare le modifiche che desidero e riconfezionarlo, sando gli strumenti standard presenti sulla maggior parte dei sistemi =.

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

A causa del n. 2, se si verifica un problema negli script "rimuovi" installati da un pacchetto che è già installato, posso risolverlo in modo banale, sando strumenti standard che esistono su qualsiasi sistema.

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

Ciò significa che la superficie per la violazione del "principio di recuperabilità" è più piccola nei pacchetti deb: da una nuova versione è possibile recuperare più errori in una versione precedente del pacchetto.

E dal momento che modificare il pacchetto è così semplice - l'attuale sovraccarico specifico per il pacchetto e la conoscenza sono minuscoli - è accessibile a più persone e richiede meno tempo e fatica, con i file deb.

4
mtraceur

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.

4
tex

Vai a cercare Google

  1. pacchetti duplicati rpm
  2. dpkg pacchetti duplicati

Leggi le pagine che ritornano. Molto indicativo che è possibile avere un database RPM incasinato con pacchetti duplicati mentre non si verifica un caso simile con dpkg.

2
user2472