Forskelle i pakkehåndtering mellem Debian og Arch

Jeg bruger bare arch regelmæssigt siden et par uger og er ingen ekspert i emnet, så dette svar er på ingen måde udtømmende, bare et par punkter, jeg har bemærket om “fleksibilitet / magt”:

• Dette er bare et indtryk, men pacman virker mere moderne og enkel i sit design / arkitektur. Der er i det mindste langt færre værktøjer at håndtere. Selvom jeg ikke kender til passende kildekode, så jeg lige tilfældigvis på libalpm-koden (det underliggende bibliotek til pacman) for at lave et meget simpelt program, og det virker rent og let at forstå.

• Det er også meget hurtigt (på grund af optimering og sandsynligvis også ved at bekymre sig om få ting (se nedenfor)). Den sidste udgivelse (pacman 3.5, et par dage gammel) forsøgte at forbedre ydeevnen ved at reducere antallet af involverede databasefiler.

• Selvom arch er orienteret mod brugen af binære pakker, har det også fordele ved opbygning af pakker fra kilden med et build-system svarende til BSDs porte ( ABS).

• Det er meget nemt og hurtigt at oprette pakker, kun et par linjer i en PKGBUILD-fil, og den er færdig, ingen grund til at håndtere kontrol / regler / copyright / changelog / hvad som helst med Debian-pakker. Og med et par klik på et web-ui deles din pakke med alle på AUR (Arch User Repository).

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

• Triggers / h ooks (hvad der gør apt til at opdatere ikonets cache, mandb eller hvad bare ved at se på, hvor pakken installerer filer, uden at pakkeren skal gøre noget) (synes der er planer at gennemføre dette).

• debconf (ingen big deal og forresten ved at tvinge mig til at gøre ting manuelt tvinger det mig til at vide, hvad der nøjagtigt er gjort) og korrekt håndtering af nye konfigurationsfiler (jeg vil i det mindste gerne have, at pacman ved, hvornår en konfigurationsfil i en ny pakkeversion adskiller sig fra den installerede, fordi den blev ændret i den nye version, eller fordi jeg ændrede den lokalt).

• pakkesignering (ser ud til at det er arbejdet på ).

For at være lys, er den eneste virkelige årsag, at den leveres med få pakker installeret som standard, og du opfordres til at tilføje det, du lige har brug for, så sandsynligvis ikke installation af valgfri afhængigheder som standard tilskynder brugerne til at installere undgå oppustethed .

Kommentarer

• Jeg kan ‘ ikke analysere dette: men jeg kan undvære det og ved forresten hvad jeg gør bedre . Der er også en skrivefejl på den sidste sætning.
• Hvilket sprog er pacman-pakkehåndteringen skrevet på? Har den lavt og højt niveau pakkehåndteringsfunktionalitet svarende til dpkg / apt, og i så fald, hvad hedder de?
• @Tshepang: undskyld, ikke-engelsk engelsk højttaler her. Jeg mente ” det er ikke en stor ting for mig at ikke have denne funktionalitet (debconf) og ved at tvinge mig til at gøre ting manuelt tvinger det mig til at vide, hvad der nøjagtigt er gjort “.
• @Faheem Mitha: Pacman er skrevet i C og er en frontend til libalpm, som håndterer begge ” høj -niveau ” og ” lavt niveau ” pakkehåndtering.
• @zanko: Jeg ‘ er heller ikke en native speaker. Alt, hvad jeg ville have dig til at gøre, er at gøre sætningen klarere og ikke i en kommentar, men på selve indlægget. BTW, den tastefejl, jeg nævnte, er optionnal . Jeg kunne selv redigere indlægget, men jeg troede, du lige så godt kunne rette det sammen med afklaringsdelen.

Jeg startede min Linux-rejse med Ubuntu lucid og bruger i øjeblikket Arch.Jeg har skrevet en håndfuld Arch-pakker, og jeg vil sige, at det er meget lettere end at skrive Debian-pakker. Men jeg vil gerne påpege for @gentledevil at Arch har et kroge-system til pakker, kendt som et install file.

Grundlæggende hedder det ${pkgname}.install, og indeholder et par funktioner til installation før / efter installation / fjernelse / opgradering; placer bare dine font-cache-opdateringer i det og så videre, og det fungerer næsten det samme som Debian-kroge.

Jeg bemærker også, at du nævnte “at fastgøre” et program ved hjælp af debian-pakkehåndteringsværktøjer; Archs pacman har den indbyggede /etc/pacman.conf accepterer også et antal indstillinger, inklusive IgnorePkg =, som forhindrer opgraderinger til pakker, der er anført efter ligestillingen (mellemrumstegnet )

Kommentarer

• Selvom det ikke er en repopakke, kan du bruge powerpill wrapper for at pacman har parallelle downloads af flere pakker, så i stedet for pacman -S libfoo libbar libbaz downloader hver pakke en efter den anden r det ville i stedet downloade alle tre samtidigt, hvilket kraftigt øger opgraderingshastighederne for bedre forbindelser.

Før jeg gå for langt, studer Billedlig Linux-tidslinje

For at forstå forskellene i pakkehåndtering skal du forstå filosofierne i operativsystemet ” es afbildet ovenfor

Tre store forældre

1. Redhat, nu Fedora – Package Manger – RPM, forkortelse for Redhat Package Manager, kommandolinje rpm
2. Slackware – Package Manager – tgz, almindelige zip-filer. Selvom disse bare er komprimerede filer, blev de bygget af Slackware opstrøms og placeret i et lager, undertiden kaldet en port
3. Debian – DEB, forkortelse for Debian, det er kommandolinjeværktøjet er Aptitude or Apt

Disse forældre er mødre og fædre til de fleste af de distributioner, vi kender i dag. Idéen / konceptet med et pakkehåndteringssystem blev afledt eller delt i nogle form eller mode. Uanset hvad er alle disse forældre binære distributører, hvilket betyder at et program pakkes og besluttes af en tredjepart, derefter gemmes i et lager og forbruges eller installeres af brugerbasen.

3 Mindre forældre

1. Linux fra bunden – kildebaseret, ingen pakkehåndtering.
2. Gentoo – Afledt fra Linux fra bunden . Denne distribution er i det væsentlige Linux fra Scratch plus en pakkehåndtering, kaldet Portage / emerge
3. SourceMage – Package Manager Sorcery

Disse forældre er mindre, fordi deres brugerbasehandler hurtig og nem installation med strøm og nem konfiguration. Hver pakke downloades og kompileres fra bunden ved hjælp af variabler og konfigurationsfiler.

Broen

Arch blev oprettet som en bro mellem en binær distribution, som en af de 3 store forældre, og en kildebaseret distribution som en af de 3 mindre forældre. Som sådan modtager den status som forælder i tidslinjen, fordi ingen andre forældre leverede denne funktionalitet. Pacman har fleksibiliteten til at tillade en bruger at installere en binær pakke fra et officielt lager eller en specialbygget pakke ved hjælp af Arch Build System. Dette koncept giver en balance mellem den magt, som de mindreårige forældre giver med den nemme installation, som de store forældre giver.

Efter min mening er det ikke pakkeadministratoren, der viser kraften i en system, da alle pakkeforvaltere udfører den samme opgave, nemlig at administrere og vedligeholde et sundt system. Som sådan skal det system, du bruger, bestemmes af faktorer som:

• Brugerniveau: Nogen nyt til linux skal starte med en større forælder, mens en teknisk dygtig vil finde en balance.
• Hvad du vil gøre med dit system: At køre en LAMP-server med tilknyttede brugere er helt anderledes end at køre en stationær pc til browsing på nettet og e-mail-læsning.
• Komfortniveau: Brugerniveau, der ikke modstår, hvis du er teknisk dygtig, men ikke vil bruge en weekend på at sammensætte et system, vælger du en større forælder, uanset om alle du kender vælger noget andet.

Kommentarer

• Dette er mere fokus brugt på geneaologien i distributionerne snarere end en sammenligning af pacman og Debian ‘ s pakkehåndteringsværktøjer …
• @jasonwryan That ‘ er pointen, da alle pakkeadministratorer udfører den samme opgave, dvs. emerge packagename er den samme som sudo apt-get install packagename.
• På det niveau ja; men det savner helt punktet i spørgsmålet, dvs. hvad der adskiller pacman fra {apt, aptitude}.
• @jasonwryan Jeg svarede det i brosektionen. Bortset fra det er der ingen forskel. De eneste forskelle er semantiske, dvs. en kommando versus en anden.Hvis OP leder efter semantiske forskelle, er der en manual til det.

Dette er ved nej betyder et komplet eller udtømmende svar – plakaterne foran mig gav allerede nogle meget gode point, jeg ville bare gerne tilføje mine 2 cent. En anden ting – jeg blev aldrig rigtig vant til apt / dpkg. Det syntes altid at være alt for kompliceret til mig, jeg er virkelig mest komfortabel med yum / rpm.

pacman er meget let at bruge, hvilket er en fordel og en fordel – du kan lære at bruge det (pakkeopbygning til side) på en enkelt eftermiddag – den bruger hovedsageligt intuitive og komplette pakkehåndteringsfunktioner, men – og dette er en stor men – det er ekstremt fleksibelt.

Hvis designerne ikke tænkte på en funktion på forhånd, er du skruet.

Et par eksempler: der er ingen native versionering i pacman. Hvis du ønsker at nedgradere en pakkeversion – skal du downloade den pågældende pakkeversion og bruge indstillingen -U (opgradering) til at installere fra filen. er meget rettet mod alwa ys ved hjælp af banebrydende pakker på dit system.

Der er ingen reel intern cache-rengøring / fuldstændig genopbygning. Hvis (pga. Et netværksproblem) en pakkehentning blev beskadiget, f.eks. Under -Syu, vil fejlmeddelelsen, selvom den er nøjagtig, ikke være til stor nytte – den vil ikke lokalisere den korrupte pakke, selv med “fuld” detaljeret og fejlretning slået til , og ingen mængde -Syyc vil virkelig rense cachen og downloade pakkerne igen. Den gode nyhed er, at -Sc vil fortælle dig, hvor de downloadede pakker er, så du simpelthen kan fjerne den fornærmende (hvis du kan finde ud af, hvilken der er) eller dem alle og genstarte -Syu.

pacman-integration med dkms er også noget problematisk – mens jeg installerede en ny kerne, havde jeg fortsat fejl fra dkms. Brug af dkms build & & dkms installerer mod den nye kerne fungeret uden hitch, men alligevel ville pacman ikke give nogen som helst information om hvorfor dkms mislykkedes under kerneopgradering (jeg formoder, at den aldrig har passeret den korrekte sti til den nye kerne, og lad bare dkms bruge standardkernen (i øjeblikket kører), men med en forkert version).

En anden anekdote om den manglende fleksibilitet – som sagde, at jeg plejede at rpm / yum. Hvis jeg har en fil på mit system, og jeg ønsker at vide, hvilken pakke der ejer den, kan jeg køre yum provides / path / to / file og få ALLE pakker, der kan placere den der – selvom ingen af dem er installeret. Hvis filen blev placeret manuelt, og nu vil jeg installere en pakke – den omdøber den nye (tilføj udvidelse .rpmnew), og lad mig vælge, hvad jeg vil bruge.

pacman fejler simpelthen, at en fil allerede findes, men med en fuldstændig irrelevant fejlmeddelelse – den klager over konflikter mellem filens “sande” ejer og den aktuelt installerede “filsystems” -pakke, som om den også er ejer af den samme fil. Det er også hovedsageligt rettet mod lokal installeret information – forsøg på at få information (såsom fillister og ejerskab) af pakker, der endnu ikke er installeret, er mindre intuitiv.

Enkelt sagt – det er ikke så modent som yum, og sandsynligvis er dpkg, som også gør det “brugervenligt, relativ ufleksibilitet.

Kommentarer

• Kort om et omfattende manglende svar, der er en række punkter, som du rejser, der virkelig er et produkt af en ukendt med Pacman. For eksempel vil pacman -Qo $file fortælle dig, hvilken pakke der ejer $ -filen. Hele dit svar er også en stråmand, da OP udtrykkeligt bad om forskelle mellem Arch og Debian – yum har intet at gøre med det …
• hvorfor jeg eksplicit afslørede denne kendsgerning i begyndelsen af mit svar. hvad angår -Qo $ filen – har du nogensinde prøvet det for en pakke, der endnu ikke er installeret?
• Der er ingen mening at prøve den for en ikke-installeret pakke; der er andre værktøjer til det. Og afsløring mindsker ikke ‘ det faktum, at du ikke har ‘ t besvarede spørgsmålet: a ” sammenligning ” mellem yum og pacman er ikke den samme som forskellene mellem Debian ‘ s og Arch ‘ s pakkehåndtering.
• @jasonwryan Selvfølgelig er der et punkt. Bare fordi du ikke ‘ ikke ser behovet for at finde ud af, hvilken pakke der muligvis ejer en fil, selvom den ‘ endnu ikke er installeret, gør det ikke ‘ t betyder, at et sådant behov ikke findes ‘ t. Det var meningen. Hvad angår andre værktøjer – er de på et behov for at vide basis? pacman er pakkehåndtering. Med hensyn til dit hovedpunkt – jeg har muligvis misforstået spørgsmålet fuldstændigt, men jeg antog, at det drejede sig om en let PM mod en mere kompleks PM. Jeg antager, at apt / dpkg er mindst lige så kompliceret som yum / rpm, funktionelt.
• Min pointe er, at du besvarer et spørgsmål om at sammenligne æbler med appelsiner ved at sammenligne din begrænsede forståelse af æbler med pærer. Og ja, du har helt forkert læst spørgsmålet …