Forskjeller i pakkehåndtering mellom Debian og Arch

Jeg bruker bare arch regelmessig siden noen uker og er ingen ekspert på temaet, så dette svaret er på ingen måte uttømmende, bare noen få punkter jeg har lagt merke til om «fleksibilitet / kraft»:

• Dette er bare et inntrykk, men pacman virker mer moderne og enkel i design / arkitektur. I det minste er det langt mindre verktøy å håndtere. Selv om jeg ikke vet om passende kildekode, så jeg tilfeldigvis på libalpm-koden (det underliggende biblioteket til Pacman) for å lage en veldig enkel oppdatering, og den virker ren og lett å forstå.

• Det er også veldig raskt (på grunn av optimalisering og sannsynligvis også ved å bry seg om få ting (se nedenfor)). Den siste utgivelsen (pacman 3.5, noen dager gammel) prøvde å forbedre ytelsen ved å redusere antall involverte databasefiler.

• Mens arch er orientert mot bruk av binære pakker, har det også fordeler når man bygger pakker fra kilden, med et byggesystem som ligner på BSDs porter ( ABS).

• Det er veldig enkelt og raskt å lage pakker, bare noen få linjer i en PKGBUILD-fil og den er ferdig, du trenger ikke å håndtere kontroll / regler / copyright / changelog / hva som helst med Debian-pakker. Og med noen få klikk på et web-ui blir pakken din delt med alle på AUR (Arch User Repository).

Ting jeg får i Debian og ikke i buen:

• Utløsere / t ooks (hva gjør apt til å oppdatere ikonbufferen, mandb eller hva som helst bare ved å se på hvor pakken installerer filer, uten at pakkeren trenger å gjøre noe) (synes det er planer å implementere dette).

• debconf (ikke så farlig og forresten ved å tvinge meg til å gjøre ting manuelt, tvinger det meg å vite hva som er gjort) og riktig håndtering av nye konfigurasjonsfiler (jeg vil i det minste ønske at pacman vet når en konfigurasjonsfil i en ny pakkeversjon er forskjellig fra den installerte fordi den ble endret i den nye versjonen eller fordi jeg endret den lokalt).

• pakkesignering (ser ut til at det jobbet med ).

For å være lys, er den eneste virkelige grunnen at den leveres med få pakker som er installert som standard, og du oppfordres til å legge til det du trenger, så det å sannsynligvis ikke installere valgfrie avhengigheter som standard oppfordrer brukerne til å installere, unngå oppblåsthet .

Kommentarer

• Jeg kan ‘ ikke analysere dette: men jeg kan klare meg uten det og forresten vite hva jeg gjør bedre . Det er også en skrivefeil på siste setning.
• Hvilket språk er pacman-pakkelederen skrevet på? Har den lavt og høyt nivå pakkehåndteringsfunksjonalitet som ligner på dpkg / apt, og i så fall hva heter de?
• @Tshepang: beklager, ikke engelsk som morsmål her. Jeg mente » dette er ikke en stor sak for meg å ikke ha denne funksjonaliteten (debconf) og ved å tvinge meg til å gjøre ting manuelt tvinger det meg til å vite hva som er gjort «.
• @Faheem Mitha: Pacman er skrevet i C, og er en frontend til libalpm, som håndterer begge » høy -nivå » og » lavt nivå » pakkehåndtering.
• @zanko: Jeg ‘ er heller ikke morsmål. Alt jeg ønsket at du skulle gjøre er å gjøre setningen tydeligere, og ikke i en kommentar, men på selve innlegget. BTW, skrivefeilen jeg nevnte er optionnal . Jeg kunne redigere innlegget selv, men jeg tenkte at du like godt kunne fikse det sammen med avklaringsdelen.

Jeg startet Linux-reisen min med Ubuntu lucid, og bruker for øyeblikket Arch.Jeg har skrevet en håndfull Arch-pakker, og jeg vil si at det er mye enklere enn å skrive Debian-pakker. Men jeg vil påpeke @gentledevil at Arch har et kroksystem for pakker, kjent som et install file.

I utgangspunktet heter den ${pkgname}.install, og inneholder noen få funksjoner for pre / post installasjon / fjerning / oppgradering; bare plasser fontoppdateringene dine i det og så videre, og det fungerer omtrent det samme som Debian-krokene.

Jeg merker også at du nevnte «å feste» et program ved hjelp av administrasjonsverktøy for Debian; Archs pacman har den innebygde i tillegg godtar /etc/pacman.conf en rekke innstillinger, inkludert IgnorePkg =, som vil forhindre oppgraderinger av alle pakker som er oppført etter likeverdiene (mellomrom )

Kommentarer

• Selv om det ikke er en repopakke, kan du bruke powerpill wrapper for at pacman skal ha parallelle nedlastinger av flere pakker, så i stedet for pacman -S libfoo libbar libbaz laster ned hver pakke en etter andre r ville det i stedet laste ned alle tre samtidig, og øke oppgraderingshastighetene sterkt for bedre tilkoblinger.

Før jeg gå for langt, studer Pictorial Linux Timeline

For å forstå forskjellene i pakkehåndtering, må du forstå filosofiene til operativsystemet » es avbildet over

Tre store foreldre

1. Redhat, Now Fedora – Package Manger – RPM, forkortelse for Redhat Package Manager, kommandolinje rpm
2. Slackware – Package Manager – tgz, vanlige zip-filer. Selv om dette bare er komprimerte filer, ble de bygget av Slackware oppstrøms og plassert i et lager, noen ganger referert til som en port
3. Debian – DEB, forkortelse for Debian, det er kommandolinjeverktøyet er Aptitude or Apt

Disse foreldrene er mødre og fedre til de fleste av distribusjonene vi kjenner i dag. Ideen / konseptet med et pakkehåndteringssystem ble avledet eller delt i noen form eller mote. Uansett er alle disse foreldrene binære distributører, noe som betyr at et program blir pakket og bestemt av en tredjepart, deretter lagret i et depot og konsumert eller installert av brukerbasen.

3 Mindre foreldre

1. Linux fra bunnen av – kildebasert, ingen pakkebehandling.
2. Gentoo – Avledet fra Linux fra Scratch . Denne distribusjonen er egentlig Linux fra Scratch pluss en pakkebehandling, kalt Portage / emerge
3. SourceMage – Package Manager Sorcery

Disse foreldrene er mindre fordi deres brukerbasebytter hastighet og enkel installasjon med kraft og enkel konfigurasjon. Hver pakke lastes ned og kompileres fra bunnen av ved hjelp av variabler og konfigurasjonsfiler.

The Bridge

Arch ble opprettet som en bro mellom en binær distribusjon, som en av de 3 store foreldrene, og en kildebasert distribusjon som en av de 3 mindre foreldrene. Som sådan får den status som foreldre i tidslinjen, fordi ingen andre foreldre ga denne funksjonaliteten. Pacman har fleksibiliteten til å tillate en bruker å installere en binær pakke fra et offisielt lager, eller en spesialbygd pakke ved hjelp av Arch Build System. Dette konseptet gir en balanse mellom kraften de mindre foreldrene gir med den enkle installasjonen som de store foreldrene gir.

Etter min mening er det ikke pakkesjefen som viser kraften til en systemet, ettersom alle pakkeforvaltere gjør den samme oppgaven, som er å administrere og opprettholde et sunt system. Som sådan bør systemet du bruker bestemmes av faktorer som:

• Brukernivå: Noen nytt for Linux bør starte med en hovedforelder, mens noen teknisk dyktige vil finne en balanse.
• Hva du vil gjøre med systemet ditt: Å kjøre en LAMP-server med tilknyttede brukere er helt annerledes enn å kjøre en stasjonær PC. for nettlesing og e-postlesing.
• Komfortnivå: Brukernivå som ikke tåler, hvis du er teknisk dyktig, men ikke vil tilbringe en helg med å kompilere et system, velger du en hovedforelder, uansett om alle du kjenner velger noe annet.

Kommentarer

• Dette er mer fokus brukt på geneaologien til distribusjonene, snarere enn en sammenligning av pacman og Debian ‘ s pakkehåndteringsverktøy …
• @jasonwryan That ‘ er poenget, ettersom alle pakkeforvaltere utfører den samme oppgaven, dvs. emerge packagename er det samme som sudo apt-get install packagename.
• På det nivået, ja; men det savner helt poenget med spørsmålet, dvs. hva som skiller pacman fra {apt, aptitude}.
• @jasonwryan Jeg svarte det i The Bridge-delen. Annet enn det er det ingen forskjell. De eneste forskjellene er semantiske, dvs. en kommando mot en annen.Hvis OP er på utkikk etter semantiske forskjeller, er det en manual for det.

Dette er ved nei betyr et fullstendig eller uttømmende svar – plakatene foran meg ga allerede veldig gode poeng, jeg vil bare legge til mine 2 øre. En annen ting – jeg ble aldri vant til apt / dpkg. Det virket alltid for komplisert å meg, jeg er veldig komfortabel med yum / rpm.

pacman er veldig enkel å bruke, noe som er en fordel og en fordel – du kan lære å bruke den (pakkeoppbygging til side) på en enkelt ettermiddag – den bruker stort sett intuitive og komplette pakkehåndteringsfunksjoner, men – og dette er et stort men – det er ekstremt lite fleksibelt.

Hvis designerne ikke tenkte på en funksjon på forhånd, er du skrudd.

Noen få eksempler: det er ingen opprinnelig versjonering i pacman. Hvis du ønsker å nedgradere en pakkeversjon – må du laste ned den spesifikke pakkeversjonen og bruke alternativet -U (oppgradering) for å installere fra filen. er veldig rettet mot alwa ys ved å bruke banebrytende pakker på systemet ditt.

Det er ingen reell intern cache-rengjøring / fullstendig ombygging. Hvis (på grunn av et nettverksproblem) en nedlasting av pakken ble ødelagt, for eksempel under -Syu, vil feilmeldingen, mens den er nøyaktig, ikke være til stor nytte – den vil ikke finne den korrupte pakken selv med «full» ordlighetsgrad og feilsøking slått på , og ingen mengder -Syyc vil virkelig rense hurtigbufferen og laste ned pakkene på nytt. Den gode nyheten er at -Sc vil fortelle deg hvor de nedlastede pakkene er, slik at du bare kan fjerne den fornærmende (hvis du kan finne ut hvilken som er) eller alle og starte på nytt -Syu.

pacman-integrering med dkms er også noe problematisk – mens jeg installerte en ny kjerne hadde jeg stadig feil fra dkms. Ved hjelp av dkms build & & dkms installerer mot den nye kjernen fungerte uten problemer, men pacman vil ikke gi noen informasjon hvorfor dkms mislyktes under kjerneoppgradering (jeg mistenker at den aldri har passert den riktige banen til den nye kjernen, og bare la dkms bruke standardkjernen (nåværende kjører), men med feil versjon).

En annen anekdote om den er ufleksibilitet – som oppgitt, jeg pleide å rpm / yum. Hvis jeg har en fil på systemet mitt og jeg ønsker å vite hvilken pakke som eier den, kan jeg kjøre yum offers / path / to / file og få ALLE pakker som kan plassere den der – selv om ingen av dem er installert. Hvis filen ble plassert manuelt, og nå ønsker jeg å installere en pakke – den vil endre navn på den nye (legg til utvidelse .rpmnew), og la meg velge hva jeg vil bruke.

pacman rett og slett feil ut at en fil allerede eksisterer, men med en helt irrelevant feilmelding – den klager over konflikter mellom filen «ekte» eier og den nåværende installerte «filsystemer» -pakken, som om den også er eier av samme fil. Det er også hovedsakelig rettet mot lokal installert informasjon – det er mindre intuitivt å prøve å få informasjon (som fillister og eierskap) av pakker som ennå ikke er installert.

Enkelt sagt – den er ikke så moden som yum, og sannsynligvis dpkg, som også gjør det enkelt å bruke, er relativ fleksibilitet.

Kommentarer

• Kort om et omfattende ikke-svar, det er en rekke poeng du tar opp som virkelig er et produkt av en ukjennlighet med Pacman. For eksempel vil pacman -Qo $file fortelle deg hvilken pakke som eier $ file. Dessuten er hele svaret ditt en stråmann da OP eksplisitt ba om forskjeller mellom Arch og Debian – yum har ingenting å gjøre med det …
• det er derfor jeg eksplisitt avslørte det faktum i begynnelsen av svaret mitt. som for -Qo $ -filen – har du noen gang prøvd det for en pakke som ennå ikke er installert?
• Det er ikke noe poeng å prøve den for en ikke-installert pakke; det er andre verktøy for det. Og avsløring ‘ t demper det faktum at du ikke har ‘ t svarte på spørsmålet: a » sammenligning » mellom yum og pacman er ikke det samme som forskjellene mellom Debian ‘ s og Arch ‘ s pakkeforvaltere.
• @jasonwryan Selvfølgelig er det et poeng. Bare fordi du ikke ‘ ikke ser behovet for å finne ut hvilken pakke som kan eie en fil, selv om den ‘ ikke er installert ennå, gjør det ikke ‘ t betyr at et slikt behov ikke eksisterer ‘ t. Det var poenget. Når det gjelder andre verktøy – er de på grunnlag av behov? pacman er pakkeleder. Når det gjelder hovedpoenget ditt – jeg kan ha lest feil spørsmål helt, men jeg antok at det dreide seg om en lett PM mot en mer kompleks PM. Jeg antar at apt / dpkg er minst like komplisert som yum / rpm, funksjonsmessig.
• Poenget mitt er at du svarer på et spørsmål om å sammenligne epler med appelsiner ved å sammenligne din begrensede forståelse av epler med pærer. Og ja, du har lest feil spørsmål helt …