Differenze nella gestione dei pacchetti tra Debian e Arch

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

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

• È anche molto veloce (a causa dellottimizzazione e probabilmente anche di poche cose (vedi sotto)). Lultima versione (pacman 3.5, vecchia di pochi giorni) ha cercato di migliorare le prestazioni riducendo il numero di file di database coinvolti.

• Sebbene arch sia orientato alluso di pacchetti binari, ha anche vantaggi quando si compila pacchetti dai sorgenti, con un sistema di compilazione simile ai port di BSD ( ABS).

• È molto facile e veloce creare pacchetti, solo poche righe in un file PKGBUILD ed è fatto, non cè bisogno di occuparsi di controllo / regole / copyright / changelog / qualunque cosa sia come con i pacchetti Debian. E in pochi clic su uninterfaccia utente web il tuo pacchetto è condiviso con tutti su AUR (Arch User Repository).

Cose che ottengo in Debian e non in arch:

• Trigger / h ooks (cosa fa in modo che apt aggiorni la cache delle icone, mandb o qualsiasi altra cosa semplicemente guardando dove il pacchetto installa i file, senza che il packager faccia nulla) (sembra che ci siano prevede di implementarlo).

• debconf (non è un grosso problema ea proposito costringendomi a fare le cose manualmente mi costringe a sapere cosa è stato fatto esattamente) e la corretta gestione dei nuovi file di configurazione (vorrei almeno che pacman sapesse quando un file di configurazione in una nuova versione del pacchetto è diverso da quello installato perché è stato modificato nella nuova versione o perché lho modificato localmente).

• firma del pacchetto (sembra che abbia lavorato ).

Perché arch sia leggero, lunica vera ragione è che viene fornito con pochi pacchetti installati di default e sei incoraggiato ad aggiungere ciò che ti serve, quindi probabilmente non installare dipendenze opzionali di default sta incitando gli utenti a installare per evitare di gonfiare .

Commenti

• Non posso ‘ analizzare questo: ma posso farne a meno e, a proposito, so cosa faccio meglio . Cè anche un errore di battitura nellultima frase.
• In che lingua è scritto il gestore di pacchetti pacman? Ha funzionalità di gestione dei pacchetti di basso e alto livello simili a dpkg / apt e, in tal caso, come si chiamano?
• @Tshepang: scusa, qui non madrelingua inglese. Volevo dire ” non è un grosso problema per me non avere questa funzionalità (debconf) e costringendomi a fare le cose manualmente mi costringe a sapere cosa viene fatto esattamente “.
• @Faheem Mitha: Pacman è scritto in C ed è un frontend per libalpm, che gestisce sia ” alto -level ” e ” basso ” gestione dei pacchetti.
• @zanko: io ‘ non sono neanche un madrelingua. Tutto quello che volevo che facessi era rendere la frase più chiara, e non in un commento, ma sul post stesso. BTW, lerrore di battitura che ho citato è opzionale . Potrei modificare il post da solo, ma ho pensato che potresti anche aggiustarlo insieme alla parte di chiarimento.

Ho iniziato il mio viaggio su Linux con Ubuntu in modo lucido e attualmente utilizzo Arch.Ho scritto una manciata di pacchetti Arch e dirò che è molto più facile che scrivere pacchetti Debian. Tuttavia, desidero far notare a @gentledevil che Arch ha un sistema di hook per i pacchetti, noto come install file.

Fondamentalmente, si chiama ${pkgname}.install e contiene alcune funzioni per pre / post installazione / rimozione / aggiornamento; è sufficiente posizionare gli aggiornamenti della cache dei caratteri in questo e così via e funziona più o meno come gli hook Debian.

Inoltre, ho notato che hai menzionato il “blocco” di unapplicazione usando gli strumenti di gestione dei pacchetti Debian; il pacman di Arch ha quello integrato inoltre, /etc/pacman.conf accetta una serie di impostazioni, tra cui IgnorePkg =, che impedirà gli aggiornamenti a tutti i pacchetti elencati dopo gli uguali (delimitato da spazi )

Commenti

• Inoltre, sebbene non sia un pacchetto repo, puoi utilizzare il powerpill wrapper affinché pacman abbia download paralleli di più pacchetti, quindi invece di pacman -S libfoo libbar libbaz scaricare ogni pacchetto uno dopo laltro r invece scaricherebbe tutti e tre contemporaneamente, aumentando notevolmente la velocità di aggiornamento per connessioni migliori.

Prima di I esagerare, studia la Timeline Linux pittorica

Per comprendere le differenze nei gestori di pacchetti, devi comprendere le filosofie del sistema operativo ” è illustrato sopra

Tre genitori principali

1. Redhat, ora Fedora – Package Manager – 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 collocati in un repository, a volte indicato come un port
3. Debian – DEB, abbreviazione di Debian, il suo strumento a riga di comando è Aptitude or Apt

Questi genitori sono madri e padri per la maggior parte delle distribuzioni che conosciamo oggi. Lidea / concetto di un sistema di gestione dei pacchetti è stato derivato o condiviso in alcuni forma o moda. 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 di utenti.

3 Genitori minori

1. Linux From Scratch – Source Based, nessun gestore di pacchetti.
2. Gentoo – Derivato da Linux from Scratch . Questa distribuzione è essenzialmente Linux da Scratch più un gestore di pacchetti, chiamato Portage / emerge
3. SourceMage – Package Manager Sorcery

Questi Genitori sono minori perché la loro base di utentiscambia 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.

The Bridge

Arch è stato creato come ponte tra una distribuzione binaria, come uno dei 3 principali genitori, e una distribuzione basata sul codice sorgente come uno dei 3 genitori minori. In quanto tale, riceve lo stato di genitore nella sequenza temporale, perché 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 utilizzando Arch Build System. Questo concetto fornisce un equilibrio tra la potenza che i genitori minori danno con la facilità di installazione che danno i genitori maggiori.

Secondo me, 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. In quanto tale, il sistema che utilizzi dovrebbe essere determinato da fattori quali:

• Livello utente: qualcuno le novità di Linux dovrebbero iniziare con un genitore principale, mentre qualcuno tecnicamente competente troverà un equilibrio.
• Cosa vuoi fare con il tuo sistema: eseguire un server LAMP con utenti collegati è completamente diverso dalleseguire un PC desktop per la navigazione sul web e la lettura di e-mail.
• Livello di comfort: livello di utente a prescindere, se sei tecnicamente esperto, ma non vuoi passare un fine settimana a compilare un sistema, sceglierai un genitore importante, indipendentemente dal fatto che tutti quelli che conosci scelgano qualcosaltro.

Commenti

• Questo è più importante basato sulla genealogia delle distribuzioni, piuttosto che un confronto tra pacman e gli strumenti di gestione dei pacchetti ‘ di Debian …
• @jasonwryan That ‘ è il punto, poiché tutti i gestori di pacchetti svolgono la stessa attività, ovvero emerge packagename è uguale a sudo apt-get install packagename.
• A quel livello, sì; ma questo manca del tutto il punto della domanda, cioè cosa differenzia pacman da {apt, aptitude}.
• @jasonwryan Ho risposto nella sezione The Bridge. A parte questo, non cè differenza. Le uniche differenze sono semantiche, cioè un comando contro un altro.Se lOP sta cercando differenze semantiche, cè un manuale per questo.

Questo è di no significa una risposta completa o esaustiva – i poster prima di me davano già ottimi punti, vorrei solo aggiungere i miei 2 centesimi. Unaltra cosa: non mi sono mai veramente abituato ad apt / dpkg. Mi è sempre sembrato troppo complesso io, sono davvero molto a mio agio con yum / rpm.

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

Se i progettisti non hanno pensato a una funzionalità in anticipo, sei “fregato”.

Alcuni esempi: non esiste un controllo delle versioni nativo in pacman. Se desideri eseguire il downgrade di una versione del pacchetto, devi scaricare quella particolare versione del pacchetto e utilizzare lopzione -U (aggiornamento) per linstallazione dal file. è molto orientato verso alwa utilizza pacchetti allavanguardia sul tuo sistema.

Non esiste una vera pulizia della cache interna / ricostruzione completa. Se (a causa di un problema di rete) il download di un pacchetto è stato danneggiato, ad esempio durante -Syu, il messaggio di errore, sebbene accurato, non sarà di grande utilità – non individuerà il pacchetto danneggiato anche con il livello di dettaglio “completo” e il debug attivati 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 che tu possa semplicemente rimuovere quello incriminato (se riesci a capire quale sia) o tutti e riavviare -Syu.

Anche lintegrazione di pacman con dkms è alquanto problematica: durante linstallazione di un nuovo kernel continuavo ad avere errori da dkms. Utilizzando dkms build & & linstallazione di dkms sul nuovo kernel ha funzionato senza intoppi, tuttavia pacman non offriva alcuna informazione sul motivo per cui dkms falliva durante il aggiornamento del kernel (sospetto che non abbia mai passato il percorso corretto del nuovo kernel, e ho lasciato che dkms usasse il kernel predefinito (attualmente in esecuzione) ma con una versione sbagliata).

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

pacman semplicemente segnala che un file è già esiste, ma con un messaggio di errore completamente irrilevante: lamenta conflitti tra il “vero” proprietario del file e il pacchetto “filesystem” attualmente installato, come se fosse anche un proprietario dello stesso file. Inoltre è per lo più orientato verso le informazioni installate in locale – cercare di ottenere informazioni (come elenchi di file e proprietà) di pacchetti non ancora installati è meno intuitivo.

In poche parole – non è maturo come yum, e probabilmente dpkg, che gli conferisce la facilità duso è anche relativa rigidità.

Commenti

• A corto di una non risposta esauriente, ci sono una serie di punti che sollevi che in realtà sono il prodotto di una non familiarità con pacman. Ad esempio pacman -Qo $file ti dirà quale pacchetto possiede $ file. Inoltre, tutta la tua risposta è un pagliaccio poiché lOP ha chiesto esplicitamente differenze tra Arch e Debian – yum non ha nulla a che fare con questo …
• che è il motivo per cui ho rivelato esplicitamente questo fatto allinizio della mia risposta. per quanto riguarda il file -Qo $ – lhai mai provato per un pacchetto non ancora installato?
• Non ha senso provarlo per un pacchetto non installato; ci sono altri strumenti per questo. E la divulgazione non ‘ mitiga il fatto che non hai ‘ t risposto alla domanda: a ” confronto ” tra yum e pacman non è uguale alle differenze tra Debian ‘ se Arch ‘ s gestori di pacchetti.
• @jasonwryan Ovviamente cè un punto. Solo perché ‘ non vedi la necessità di capire quale pacchetto potrebbe possedere un file anche se ‘ non è ancora installato, non ‘ non significa che tale esigenza ‘ non esiste. Questo era il punto. Per quanto riguarda gli altri strumenti, sono in base alla necessità di sapere? pacman è il gestore dei pacchetti. Per quanto riguarda il tuo punto principale, potrei aver letto completamente male la domanda, ma ho pensato che si trattasse di un PM leggero rispetto a un PM più complesso. Presumo che apt / dpkg sia complesso almeno quanto yum / rpm, dal punto di vista delle funzionalità.
• Il 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 letto completamente male la domanda …