Differenze nella gestione dei pacchetti tra Debian e Arch


9

Una discussione di questo post mi ha incuriosito delle differenze tra la gestione dei pacchetti Debian e Arch. Inoltre, la gente tende a dire che Arch è molto leggero, quindi mi chiedo cosa abbia a che fare con la gestione dei pacchetti. E 'forse perché Debian considera Raccomanda come dipendenze duri per impostazione predefinita?

Puoi anche menzionare la flessibilità / potenza tra i due gestori di pacchetti: quale dei due ti consente di fare di più.

Sono consapevole che alcune funzionalità disponibili su un sistema di gestione dei pacchetti Debian sarebbero irrilevanti su un sistema Arch, dal momento che Arch ha una singola Suite e Debian ne ha diverse (ad esempio, il pin APT e la gestione avanzata della dipendenza), quindi si prega di confrontare le funzionalità che sono applicabili ad entrambi i sistemi (ovvero suppongo che per Debian io utilizzi solo unstable ).


NOTA : Con la gestione dei pacchetti Debian mi riferisco ad APT, aptitude e dpkg. Non ho familiarità con gli strumenti Arch, quindi non so se ci sia qualcosa di diverso da Pacman.
Tshepang,

Risposte:


7

Uso solo arco regolarmente da alcune settimane e non sono un esperto in materia, quindi questa risposta non è affatto esaustiva, solo alcuni punti che ho notato sulla "flessibilità / potenza":

  • Questa è solo un'impressione, ma Pacman sembra più moderno e semplice nel suo design / architettura. Almeno ci sono molti meno strumenti da affrontare. Anche se non conosco il codice sorgente apt, mi è capitato di guardare il codice libalpm (la libreria sottostante di pacman) per creare una patch molto semplice e sembra pulito e facile da capire.

  • È anche molto veloce (a causa dell'ottimizzazione e probabilmente anche preoccupandosi di poche cose (vedi sotto)). L'ultima versione (pacman 3.5, alcuni giorni fa) ha cercato di migliorare le prestazioni riducendo il numero di file di database coinvolti.

  • Mentre arch è orientato all'utilizzo di pacchetti binari, presenta anche vantaggi nella creazione di pacchetti da sorgenti, con un sistema di compilazione simile alle porte di BSD (ABS).

  • È molto facile e veloce creare pacchetti, solo poche righe in un file PKGBUILD e il suo fatto, non c'è bisogno di occuparsi di controllo / regole / copyright / log delle modifiche / come qualsiasi altro con i pacchetti Debian. E in pochi clic su un'interfaccia web il tuo pacchetto è condiviso con tutti su AUR (Arch User Repository).

Cose che ottengo in Debian e non in arco:

  • Trigger / hook (cosa rende apt aggiornare la cache delle icone, il mandb o qualunque altra cosa semplicemente guardando dove sono installati i file del pacchetto, senza che il packager faccia nulla) (sembra che ci siano piani per implementarlo).

  • debconf (non è un grosso problema e, a proposito, costringendomi a fare le cose manualmente mi costringe a sapere cosa viene fatto esattamente) e la corretta gestione di nuovi file di configurazione (vorrei almeno che pacman sapesse quando un file di configurazione in un nuovo pacchetto la versione è diversa da quella installata perché è stata modificata nella nuova versione o perché l'ho modificata localmente).

  • firma del pacchetto (sembra che si stia lavorando ).

Per la luce dell'arco, l'unica vera ragione è che viene fornito con alcuni pacchetti installati per impostazione predefinita e sei incoraggiato ad aggiungere ciò di cui hai solo bisogno, quindi probabilmente non installare dipendenze opzionali per impostazione predefinita è incoraggiare gli utenti a installare evitare il gonfiamento.


Non posso analizzarlo: ma posso farne a meno e, a proposito, sapere cosa faccio meglio . C'è anche un refuso sull'ultima frase.
Tshepang,

In che lingua è scritto il gestore pacchetti pacman? Ha funzionalità di gestione dei pacchetti di basso e alto livello simili a dpkg / apt e, in tal caso, come si chiamano?
Faheem Mitha,

@Tshepang: scusa, non madrelingua inglese qui. Intendevo "questo non è un grosso problema per me non avere questa funzionalità (debconf) e costringendomi a fare le cose manualmente mi costringe a sapere cosa è fatto esattamente".
gentledevil,

@Faheem Mitha: Pacman è scritto in C ed è un frontend per libalpm, che gestisce sia la gestione dei pacchetti "di alto livello" che "di basso livello".
gentledevil,

@zanko: Non sono neanche un madrelingua. Tutto quello che volevo farti è rendere la frase più chiara, non in un commento, ma sul post stesso. A proposito, il refuso che ho citato è opzionale . Potrei modificare il post da solo, ma ho pensato che potresti anche risolverlo insieme alla parte di chiarimento.
Tshepang,

6

Ho iniziato il mio viaggio Linux con Ubuntu lucido e attualmente uso Arch. Ho scritto una manciata di pacchetti Arch e dirò che è molto più semplice che scrivere pacchetti Debian. Ma, vorrei sottolineare a @gentledevil che Arch ha un sistema di hook per i pacchetti, noto come install file.

Fondamentalmente, prende il nome ${pkgname}.installe contiene alcune funzioni per pre / post installazione / rimozione / aggiornamento; basta inserire gli aggiornamenti della cache dei font in quello e così via e funziona quasi allo stesso modo degli hook di Debian.

Inoltre, noto che hai menzionato "bloccare" un'applicazione usando gli strumenti di gestione dei pacchetti debian; Arch's pacman ha anche quello incorporato, /etc/pacman.confaccetta una serie di impostazioni, tra cui IgnorePkg =, che impediranno gli aggiornamenti di tutti i pacchetti elencati dopo il uguale (delimitato da spazi)


1
Inoltre, sebbene non sia un pacchetto repo, è possibile utilizzare il powerpillwrapper per pacman per avere download paralleli di più pacchetti, quindi invece di pacman -S libfoo libbar libbazscaricare ogni pacchetto uno dopo l'altro, scarica invece tutti e tre contemporaneamente, aumentando notevolmente le velocità di aggiornamento per connessioni migliori.
hanetzer

-1

Prima di andare troppo lontano, studia la linea temporale pittorica di Linux

Per comprendere le differenze tra i gestori di pacchetti, è necessario comprendere le filosofie dei sistemi operativi illustrate sopra


Tre genitori principali

  1. Redhat, Now Fedora - Package Manger - RPM, abbreviazione di Redhat Package Manager, riga di comando rpm
  2. Slackware - Package Manager - tgz, normali file zippati. Sebbene questi siano solo file compressi, sono stati creati da Slackware a monte e inseriti in un repository, a volte indicato come porta
  3. Debian - DEB, abbreviazione di Debian, è lo strumento da riga di comando Aptitude or Apt

Questi genitori sono madri e padri della maggior parte delle distribuzioni che conosciamo oggi. L'idea / concetto di un sistema di gestione dei pacchetti è stato derivato o condiviso in una forma o modo. Indipendentemente da ciò, tutti questi genitori sono distributori binari, il che significa che un programma viene impacchettato e deciso da una terza parte, quindi archiviato in un repository e consumato o installato dalla base utenti.

3 genitori minori

  1. Linux From Scratch - Basato su sorgente, nessun gestore di pacchetti.
  2. Gentoo - Derivato da Linux da Scratch . Questa distribuzione è essenzialmente Linux da Scratch più un gestore di pacchetti, chiamato Portage / emerge
  3. SourceMage - Stregoneria del gestore pacchetti

Questi genitori sono minori perché la loro base di utenti scambia velocità e facilità di installazione con potenza e facilità di configurazione. Ogni pacchetto viene scaricato e compilato da zero, utilizzando variabili e file di configurazione.

Il ponte

Arch è stato creato come un ponte tra una distribuzione binaria, come uno dei 3 genitori principali, e una distribuzione basata sulla sorgente come uno dei 3 genitori minori. Come tale, riceve lo stato come genitore nella sequenza temporale, poiché nessun altro genitore ha fornito questa funzionalità. Pacman ha la flessibilità di consentire a un utente di installare un pacchetto binario da un repository ufficiale o un pacchetto personalizzato che utilizza Arch Build System. Questo concetto fornisce un equilibrio tra il potere conferito dai genitori minori alla facilità di installazione offerta dai genitori maggiori.


A mio avviso, non è il gestore di pacchetti che mostra la potenza di un sistema, poiché tutti i gestori di pacchetti svolgono la stessa attività, ovvero gestire e mantenere un sistema integro. Pertanto, il sistema utilizzato dovrebbe essere determinato da fattori quali:

  • Livello utente: qualcuno che non conosce Linux dovrebbe iniziare con un genitore maggiore, mentre qualcuno tecnicamente competente troverà un equilibrio.
  • Cosa vuoi fare con il tuo sistema: eseguire un server LAMP con utenti collegati è totalmente diverso rispetto a un PC desktop per la navigazione web e la lettura della posta elettronica.
  • Livello di comfort: il livello dell'utente non deve resistere, se sei tecnicamente competente, ma non vuoi trascorrere un weekend a compilare un sistema, sceglierai un genitore principale, indipendentemente dal fatto che tutti quelli che conosci scelgano qualcos'altro.

Questo è più focalizzato sulla geneaologia delle distribuzioni, piuttosto che un confronto tra pacman e gli strumenti di gestione dei pacchetti di Debian ...
jasonwryan,

@jasonwryan Questo è il punto, dato che tutti i gestori di pacchetti svolgono lo stesso compito, ovvero emerge packagenamelo stesso di sudo apt-get install packagename.
eyoung100,

A quel livello, sì; ma questo non rispecchia completamente il punto della domanda, vale a dire, ciò che differenzia pacman da {apt, aptitude}.
Jasonwryan,

@jasonwryan ho risposto che nella sezione The Bridge. A parte questo, non c'è differenza. Le uniche differenze sono semantiche, cioè un comando contro un altro. Se l'OP cerca differenze semantiche, esiste un manuale per questo.
eyoung100,

-3

Questa non è affatto una risposta completa o esaustiva: i poster che avevo davanti mi davano già degli ottimi punti, vorrei solo aggiungere i miei 2 centesimi. Un'altra cosa: non mi sono mai abituato a apt / dpkg. Mi è sempre sembrato troppo complesso, mi sento davvero a mio agio con yum / rpm.

pacman è molto facile da usare, che è un pro e un contro - puoi imparare ad usarlo (creazione di pacchetti a parte) in un solo pomeriggio - usa funzionalità di gestione dei pacchetti per lo più intuitive e complete, ma - e questo è un grande ma - è estremamente inflessibile.

Se i progettisti non hanno pensato prima a una funzione, sei fregato.

Alcuni esempi: non esiste un versioning nativo in pacman. Se desideri effettuare il downgrade di una versione del pacchetto, devi scaricare quella particolare versione del pacchetto e utilizzare l'opzione -U (aggiornamento) per installare dal file. È molto orientato all'utilizzo sempre di pacchetti all'avanguardia sul tuo sistema.

Non esiste una vera pulizia della cache interna / ricostruzione completa. Se (a causa di un problema di rete) un download del pacchetto è stato corrotto, ad esempio durante -Syu, il messaggio di errore, sebbene accurato, non sarà di grande utilità - non individuerà il pacchetto corrotto anche con la verbosità "completa" e il debug attivato e nessuna quantità di -Syyc pulirà davvero la cache e scaricherà nuovamente i pacchetti. La buona notizia è che -Sc ti farà sapere dove sono i pacchetti scaricati in modo da poter semplicemente rimuovere quello offensivo (se riesci a capire quale sia) o tutti e riavviare -Syu.

Anche l'integrazione di pacman con dkms è alquanto problematica - durante l'installazione di un nuovo kernel ho continuato ad avere errori da dkms. Usando dkms build && dkms install contro il nuovo kernel ha funzionato senza intoppi, ma pacman non avrebbe fornito alcuna informazione sul motivo per cui dkms non è riuscito durante l'aggiornamento del kernel (sospetto che non abbia mai superato il percorso corretto del nuovo kernel, e lascia che dkms usi il valore predefinito (attualmente in esecuzione) kernel ma con versione errata).

Un altro aneddoto sulla sua inflessibilità - come detto, sono abituato a rpm / yum. Se ho un file sul mio sistema e desidero sapere quale pacchetto lo possiede, posso eseguire yum fornisce / path / to / file e ottenere TUTTI i pacchetti che possono metterlo lì, anche se nessuno di essi è installato. Se il file è stato inserito manualmente e ora desidero installare un pacchetto, rinominerà quello nuovo (aggiungi l'estensione .rpmnew) e lasciami scegliere cosa usare.

pacman semplicemente fa un errore del fatto che un file esiste già, ma con un messaggio di errore completamente irrilevante - si lamenta dei conflitti tra il proprietario del file "vero" e il pacchetto "filesystems" attualmente installato, come se fosse anche il proprietario dello stesso file. Inoltre è principalmente orientato verso le informazioni installate locali: cercare di ottenere informazioni (come elenchi di file e proprietà) di pacchetti non ancora installati è meno intuitivo.

In poche parole: non è maturo come lo yum, e probabilmente dpkg, che si presta alla sua facilità d'uso e alla relativa inflessibilità.


1
A corto di una non risposta completa, ci sono una serie di punti che sollevi che sono davvero il prodotto di una familiarità con pacman. Ad esempio, pacman -Qo $fileti dirà quale pacchetto possiede $ file. Inoltre, la tua intera risposta è un pagliaccio poiché l'OP ha esplicitamente chiesto differenze tra Arch e Debian - yumnon ha nulla a che fare con esso ...
jasonwryan,

ed è per questo che ho esplicitamente rivelato questo fatto all'inizio della mia risposta. come per il file -Qo $ - l'hai mai provato per un pacchetto non ancora installato?
Dani_l,

Non ha senso provarlo per un pacchetto non installato; ci sono altri strumenti per quello. E la divulgazione non mitiga il fatto che non hai risposto alla domanda: un "confronto" tra yum e pacman non è lo stesso delle differenze tra i gestori di pacchetti di Debian e Arch.
Jasonwryan,

@jasonwryan Naturalmente c'è un punto. Solo perché non vedi la necessità di capire quale pacchetto potrebbe possedere un file anche se non è ancora installato, non significa che tale necessità non esiste. Questo era il punto. Per quanto riguarda gli altri strumenti, hanno bisogno di conoscere le basi? pacman è il gestore dei pacchetti. Per quanto riguarda il punto principale, potrei aver frainteso completamente la domanda, ma ho ipotizzato che si trattasse di un PM leggero rispetto a un PM più complesso. Presumo che apt / dpkg sia almeno complesso quanto yum / rpm, per quanto riguarda le funzionalità.
Dani_l,

Il mio punto è che stai rispondendo a una domanda sul confronto tra mele e arance confrontando la tua comprensione limitata delle mele con le pere. E sì, hai completamente frainteso la domanda ...
Jasonwryan,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.