Skillnader i pakethantering mellan Debian och Arch

Jag använder bara arch regelbundet sedan några veckor och är ingen expert i ämnet så detta svar är inte alls uttömmande, bara några punkter jag har noterat om ”flexibilitet / kraft”:

• Detta är bara ett intryck men pacman verkar mer modern och enkel i sin design / arkitektur. Det finns åtminstone mycket mindre verktyg att hantera. Medan jag inte känner till lämplig källkod, så råkade jag bara titta på libalpm-koden (det underliggande biblioteket till Pacman) för att göra en mycket enkel patch, och det verkar rent och lätt att förstå.

• Det går också väldigt snabbt (på grund av optimering och troligen också genom att bry sig om få saker (se nedan)). Den senaste versionen (pacman 3.5, några dagar gammal) försökte förbättra prestanda genom att minska antalet involverade databasfiler.

• Även om arch är inriktat på användning av binära paket har det också fördelar när man bygger paket från källan, med ett byggsystem som liknar BSD: s portar ( ABS).

• Det är väldigt enkelt och snabbt att skapa paket, bara några rader i en PKGBUILD-fil och den är klar, du behöver inte hantera kontroll / regler / copyright / changelog / vad som helst med Debian-paket. Och med några få klick på ett webb-ui delas ditt paket med alla i AUR (Arch User Repository).

Saker jag får i Debian och inte i arch:

• Triggers / h ooks (vad gör apt att uppdatera ikonens cache, mandb eller vad som helst bara genom att titta på var paketet installerar filer, utan att paketeraren behöver göra något) (verkar det finns planerar att genomföra detta).

• debconf (ingen stor sak och förresten genom att tvinga mig att göra saker manuellt tvingar det mig att veta exakt vad som görs) och korrekt hantering av nya konfigurationsfiler (jag skulle åtminstone vilja att pacman skulle veta när en konfigurationsfil i en ny paketversion skiljer sig från den installerade eftersom den ändrades i den nya versionen eller för att jag modifierade den lokalt).

• paketsignering (verkar att det är arbetat med ).

För att bågen är lätt, är den enda verkliga anledningen att den levereras med få paket installerade som standard och du uppmanas att lägga till vad du behöver, så förmodligen att inte installera valfria beroenden som standard uppmuntrar användare att installera undvik uppblåsthet .

Kommentarer

• Jag kan ’ inte analysera detta: men jag kan klara mig utan det och förresten veta vad jag gör bättre . Det finns också ett stavfel på den sista meningen.
• Vilket språk är pacman-pakethanteraren skriven på? Har den lågnivå- och högnivåpakethanteringsfunktionalitet som liknar dpkg / apt, och i så fall vad heter de?
• @Tshepang: förlåt, engelska som inte är infödd här. Jag menade ” detta är inte en stor sak för mig att inte ha denna funktionalitet (debconf) och genom att tvinga mig att göra saker manuellt tvingar det mig att veta vad som exakt görs ”.
• @Faheem Mitha: Pacman är skriven i C och är en frontend till libalpm, som hanterar båda ” hög -nivå ” och ” låg nivå ” pakethantering.
• @zanko: Jag ’ är inte heller modersmål. Allt jag ville att du skulle göra är att göra meningen tydligare och inte i en kommentar utan på inlägget i sig. BTW, typsnittet jag nämnde är optionnal . Jag kunde redigera inlägget själv, men jag tänkte att du lika gärna skulle kunna fixa det tillsammans med förtydligande delen.

Jag började min Linux-resa med Ubuntu lucid och använder för närvarande Arch.Jag har skrivit en handfull Arch-paket och jag säger att det är mycket enklare än att skriva Debian-paket. Men jag vill påpeka för @gentledevil att Arch har ett kroksystem för paket, så kallat install file.

I grund och botten heter det ${pkgname}.install, och innehåller några funktioner för installation före / efter installation / borttagning / uppgradering; placera bara dina font-cache-uppdateringar i det och så vidare och det fungerar på ungefär samma sätt som Debian-krokarna.

Jag märker också att du nämnde att ”fästa” en applikation med hjälp av Debian-pakethanteringsverktyg; Archs pacman har den inbyggda /etc/pacman.conf accepterar också ett antal inställningar, inklusive IgnorePkg =, vilket förhindrar uppgraderingar av alla paket som anges efter lika (space-avgränsad )

Kommentarer

• Även om det inte är ett repopaket kan du använda powerpill omslag för att pacman ska ha parallella nedladdningar av flera paket, så istället för att pacman -S libfoo libbar libbaz ladda ner varje paket efter andra r det skulle istället ladda ner alla tre samtidigt, vilket kraftigt ökar uppgraderingshastigheterna för bättre anslutningar.

Innan jag gå för långt, studera Picturell Linux-tidslinje

För att förstå skillnaderna i pakethanterare måste du förstå filosofierna för operativsystemet ” es avbildad ovan

Tre stora föräldrar

1. Redhat, nu Fedora – Package Manger – RPM, förkortning för Redhat Package Manager, kommandorad rpm
2. Slackware – Package Manager – tgz, vanliga zippade filer. Även om det här bara är komprimerade filer, byggdes de av Slackware uppströms och placerades i ett förvar, ibland kallat en port
3. Debian – DEB, förkortning för Debian, det är kommandoradsverktyget är Aptitude or Apt

Dessa föräldrar är mödrar och fäder till de flesta av de distributioner vi känner idag. Idén / konceptet med ett pakethanteringssystem härleddes eller delades i vissa Oavsett, alla dessa föräldrar är binära distributörer, vilket innebär att ett program packas och bestäms av en tredje part, lagras sedan i ett arkiv och konsumeras eller installeras av användarbasen.

3 Mindre föräldrar

1. Linux From Scratch – Source Based, no package manager.
2. Gentoo – Hämtat från Linux från Scratch . Denna distribution är i huvudsak Linux från Scratch plus en pakethanterare, kallad Portage / emerge
3. SourceMage – Package Manager Sorcery

Dessa föräldrar är mindre eftersom deras användarbasbyter hastighet och enkel installation med kraft och enkel konfiguration. Varje paket laddas ner och kompileras från grunden med hjälp av variabler och konfigurationsfiler.

Bron

Arch skapades som en bro mellan en binär distribution, som en av de 3 stora föräldrarna, och en källbaserad distribution som en av de tre mindre föräldrarna. Som sådan får den status som förälder i tidslinjen, eftersom ingen annan förälder tillhandahöll denna funktionalitet. Pacman har flexibiliteten att tillåta en användare att installera ett binärt paket från ett officiellt arkiv eller ett specialbyggt paket med Arch Build System. Detta koncept ger en balans mellan den kraft som de mindre föräldrarna ger med den enkla installation som de stora föräldrarna ger.

Enligt min mening är det inte pakethanteraren som visar kraften i en system, eftersom alla pakethanterare gör samma uppgift, det vill säga att hantera och underhålla ett hälsosamt system. Som sådant bör systemet du använder bestämmas av faktorer som:

• Användarnivå: Någon nytt för linux bör börja med en större förälder, medan någon tekniskt skicklig hittar en balans.
• Vad du vill göra med ditt system: Att köra en LAMP-server med anslutna användare är helt annorlunda än att köra en stationär dator för webbsurfning och e-postläsning.
• Komfortnivå: Användarnivå som inte klarar, om du är tekniskt skicklig men inte vill spendera en helg på att sammanställa ett system, väljer du en större förälder, oavsett om alla du känner väljer något annat.

Kommentarer

• Detta är mer fokus använde distributionens geneaologi snarare än en jämförelse mellan pacman och Debian ’ s pakethanteringsverktyg …
• @jasonwryan That ’ är poängen, eftersom alla pakethanterare utför samma uppgift, dvs emerge packagename är samma som sudo apt-get install packagename.
• På den nivån, ja; men det saknar helt punkten i frågan, dvs vad skiljer pacman från {apt, aptitude}.
• @jasonwryan Jag svarade det i avsnittet The Bridge. Annat än det är det ingen skillnad. De enda skillnaderna är semantiska, det vill säga ett kommando mot ett annat.Om OP: n letar efter semantiska skillnader finns det en manual för det.

Detta är av nej betyder ett fullständigt eller uttömmande svar – affischerna framför mig gav redan några mycket bra poäng, jag skulle bara vilja lägga till mina 2 cent. En annan sak – jag har aldrig riktigt vant mig vid apt / dpkg. Det verkade alltid vara för komplicerat att mig, jag är verkligen bekvämast med yum / rpm.

pacman är väldigt lätt att använda, vilket är ett proffs och ett nackdel – du kan lära dig att använda det (paketbyggnad åt sidan) på en enda eftermiddag – den använder mestadels intuitiva och kompletta pakethanteringsfunktioner, men – och detta är en stor men – det är extremt flexibel.

Om formgivarna inte tänkte på en funktion i förväg är du skruvad.

Några exempel: det finns ingen inbyggd version i pacman. Om du vill nedgradera en paketversion – måste du ladda ner den specifika paketversionen och använda alternativet -U (uppgradering) för att installera från filen. är mycket inriktad på alwa ys använder avancerade paket på ditt system.

Det finns ingen verklig intern cacherengöring / fullständig ombyggnad. Om (på grund av ett nätverksproblem) en nedladdning av paketet var skadad, t.ex. under -Syu, kommer felmeddelandet, även om det är korrekt, inte till stor nytta – det kommer inte att identifiera det korrupta paketet även med ”full” ordalighet och felsökning aktiverad , och ingen mängd -Syyc kommer verkligen att rensa cacheminnet och ladda ner paketen igen. Den goda nyheten är att -Sc kommer att låta dig veta var de nedladdade paketen är så att du helt enkelt kan ta bort den kränkande (om du kan ta reda på vilken som är) eller alla och starta om -Syu.

pacman-integration med dkms är också något problematiskt – medan jag installerade en ny kärna hade jag fortfarande fel från dkms. Med hjälp av dkms build & & dkms installerar mot den nya kärnan fungerade utan problem, men pacman skulle inte ge någon information alls varför dkms misslyckades under kärnuppgradering (jag misstänker att den aldrig passerade rätt sökväg för den nya kärnan, och bara låta dkms använda standardkärnan (nuvarande körning) men med fel version).

En annan anekdot om den är oflexibilitet – som uppgav, jag brukade rpm / yum. Om jag har en fil på mitt system och jag vill veta vilket paket som äger det, kan jag köra yum provides / path / to / file och få ALLA paket som kan placera den där – även om ingen av dem är installerade. Om filen placerades manuellt och nu vill jag installera ett paket – det kommer att byta namn på det nya (lägg till tillägget .rpmnew), och låt mig välja vad jag ska använda.

pacman felar helt enkelt ut att en fil redan existerar, men med ett helt irrelevant felmeddelande – det klagar över konflikter mellan filens ”sanna” ägare och det för närvarande installerade ”filsystem” -paketet, som om det också är ägare till samma fil. Det är också främst inriktat på lokal installerad information – att försöka få information (som fillistor och ägande) av paket som ännu inte är installerade är mindre intuitivt.

Enkelt uttryckt – det är inte lika moget som yum, och förmodligen dpkg, vilket också gör att ”användarvänligheten är relativ oflexibilitet.

Kommentarer

• Kort om ett omfattande icke-svar, det finns ett antal punkter som du tar upp som verkligen är en produkt av en obekant med Pacman. Till exempel pacman -Qo $file berättar vilket paket som äger $ -filen. Hela ditt svar är också en stråman eftersom OP uttryckligen bad om skillnader mellan Arch och Debian – yum har inget att göra med det …
• vilket är anledningen till att jag uttryckligen avslöjade det faktum i början av mitt svar. när det gäller -Qo $ -filen – har du någonsin provat det för ett paket som ännu inte är installerat?
• Det är ingen mening att prova det för ett icke-installerat paket; det finns andra verktyg för det. Och avslöjande minskar inte ’ t det faktum att du inte har ’ t besvarade frågan: a ” jämförelse ” mellan yum och pacman är inte samma som skillnaderna mellan Debian ’ s och Arch ’ s pakethanterare.
• @jasonwryan Naturligtvis finns det en poäng. Bara för att du inte ’ inte ser behovet av att ta reda på vilket paket som kan äga en fil även om den ’ inte är installerad ännu, inte ’ t betyder att ett sådant behov inte finns ’ t. Det var meningen. När det gäller andra verktyg – har de behov av kunskap? pacman är pakethanteraren. När det gäller din huvudsakliga punkt – jag kanske har läst frågan helt, men jag antog att det handlade om en lätt PM mot en mer komplex PM. Jag antar att apt / dpkg är minst lika komplex som yum / rpm, funktionellt.
• Min poäng är att du svarar på en fråga om att jämföra äpplen med apelsiner genom att jämföra din begränsade förståelse av äpplen med päron. Och ja, du har helt felläst frågan …