Verschillen in pakketbeheer tussen Debian en Arch

Ik gebruik arch sinds een paar weken regelmatig en ben geen expert op dit gebied, dus dit antwoord is zeker niet uitputtend, slechts een paar punten die ik heb opgemerkt over de “flexibiliteit / kracht”:

• Dit is slechts een indruk, maar pacman lijkt moderner en eenvoudiger in zijn ontwerp / architectuur. Er zijn in ieder geval veel minder tools om mee om te gaan. Hoewel ik de broncode van apt niet weet, keek ik toevallig naar de libalpm-code (de onderliggende bibliotheek van pacman) om een heel eenvoudige patch te maken, en het lijkt schoon en gemakkelijk te begrijpen.

• Het is ook erg snel (vanwege optimalisatie en waarschijnlijk ook door om een paar dingen te geven (zie hieronder)). De laatste release (pacman 3.5, een paar dagen oud) probeerde de prestaties te verbeteren door het aantal betrokken databasebestanden.

• Hoewel arch gericht is op het gebruik van binaire pakketten, heeft het ook voordelen bij het bouwen van pakketten vanaf de broncode, met een bouwsysteem vergelijkbaar met de poorten van BSD ( ABS).

• Het is heel gemakkelijk en snel om pakketten te maken, slechts een paar regels in een PKGBUILD-bestand en het is klaar, je hoeft je niet bezig te houden met controle / regels / copyright / changelog / wat dan ook met Debian-pakketten. En met een paar klikken op een webinterface wordt uw pakket gedeeld met iedereen op AUR (Arch User Repository).

Dingen die ik krijg in Debian en niet in arch:

• Triggers / h ooks (wat ervoor zorgt dat apt de pictogramcache, de mandb of wat dan ook bijwerkt door te kijken naar waar de installatiebestanden van het pakket zijn, zonder dat de packager iets hoeft te doen) (het lijkt erop dat er plannen om dit te implementeren).

• debconf (geen probleem en trouwens door me te dwingen dingen handmatig te doen, dwingt het me te weten wat er precies wordt gedaan) en juiste afhandeling van nieuwe configuratiebestanden (ik zou in ieder geval willen dat pacman weet wanneer een configuratiebestand in een nieuwe pakketversie anders is dan de geïnstalleerde versie omdat het in de nieuwe versie is gewijzigd of omdat ik het lokaal heb gewijzigd).

• pakketondertekening (het lijkt erop dat er aan heeft gewerkt ).

Omdat arch licht is, is de enige echte reden dat er standaard een paar pakketten zijn geïnstalleerd en je wordt aangemoedigd om toe te voegen wat je nodig hebt, dus het is waarschijnlijk dat het niet installeren van optionele afhankelijkheden standaard is om gebruikers aan te zetten om te installeren om bloat te voorkomen .

Reacties

• Ik kan ‘ t ontleden: maar ik kan het zonder en weet trouwens wat ik beter kan . Er is ook een typefout in de laatste zin.
• In welke taal is de pacman-pakketbeheerder geschreven? Heeft het pakketbeheerfunctionaliteit op laag en hoog niveau vergelijkbaar met dpkg / apt, en zo ja, hoe worden ze genoemd?
• @Tshepang: sorry, niet-native speaker Engels hier. Ik bedoelde ” dit is niet erg voor mij om deze functionaliteit niet te hebben (debconf) en door me te dwingen dingen handmatig te doen, dwingt het me te weten wat er precies wordt gedaan “.
• @Faheem Mitha: Pacman is geschreven in C, en is een frontend voor libalpm, die beide ” high afhandelt -level ” en ” low-level ” pakketbeheer.
• @zanko: ik ‘ ben ook geen moedertaalspreker. Het enige wat ik wilde dat je deed, is de zin duidelijker maken, en niet in een opmerking, maar op het bericht zelf. Trouwens, de typfout die ik noemde is optioneel . Ik zou het bericht zelf kunnen bewerken, maar ik dacht dat je het net zo goed samen met het verduidelijkingsgedeelte kon repareren.

Ik begon mijn Linux-reis met Ubuntu lucid en gebruik momenteel Arch.Ik heb een handvol Arch-pakketten geschreven en ik zal zeggen dat het veel gemakkelijker is dan het schrijven van Debian-pakketten. Maar ik “wil @gentledevil erop wijzen dat Arch wel een hooks-systeem heeft voor pakketten, bekend als een install file.

In feite heet het ${pkgname}.install, en het bevat een paar functies voor pre / post installatie / verwijdering / upgrade; plaats gewoon je font-cache updates in dat, enzovoort, en het werkt ongeveer hetzelfde als de Debian-hooks.

Ik merk ook dat je het hebt gehad over het “vastzetten” van een applicatie met behulp van debian-hulpprogrammas voor pakketbeheer; Archs pacman heeft dat ingebouwd en /etc/pacman.conf accepteert ook een aantal instellingen, waaronder IgnorePkg =, die upgrades naar pakketten die na de gelijken staan (spaties gescheiden )

Reacties

• Hoewel het geen repo-pakket is, kun je ook de powerpill wrapper gebruiken voor pacman om parallelle downloads van meerdere pakketten te hebben, dus in plaats van pacman -S libfoo libbar libbaz downloadt elk pakket een na de andere r het zou in plaats daarvan alle drie tegelijk downloaden, waardoor de upgradesnelheden aanzienlijk toenemen voor betere verbindingen.

Voordat ik ga te ver, bestudeer de Pictorial Linux Timeline

Om de verschillen in pakketbeheerders te begrijpen, moet je de filosofieën van het besturingssysteem begrijpen ” es hierboven afgebeeld

Drie belangrijke ouders

1. Redhat, nu Fedora – pakketbeheerder – RPM, afkorting voor Redhat Package Manager, opdrachtregel rpm
2. Slackware – Pakketbeheerder – tgz, gewone gezipte bestanden. Hoewel dit slechts gecomprimeerde bestanden zijn, werden ze stroomopwaarts door Slackware gebouwd en in een repository geplaatst, soms een poort genoemd
3. Debian – DEB, een afkorting van Debian, het opdrachtregelprogramma is Aptitude or Apt

Deze ouders zijn moeders en vaders van de meeste distributies die we tegenwoordig kennen. Het idee / concept van een pakketbeheersysteem is afgeleid of gedeeld in sommige Hoe dan ook, al deze ouders zijn binaire distributeurs, wat betekent dat een programma wordt verpakt en beslist door een derde partij, vervolgens wordt opgeslagen in een repository en wordt gebruikt of geïnstalleerd door de gebruikers.

3 Minderjarige ouders

1. Linux From Scratch – Brongebaseerd, geen pakketbeheerder.
2. Gentoo – Afgeleid van Linux van Scratch . Deze distributie is in wezen Linux from Scratch plus een pakketbeheerder, genaamd Portage / emerge
3. SourceMage – Pakketbeheerder Sorcery

Deze ouders zijn klein omdat hun gebruikersbasishandelt snelheid en installatiegemak af met kracht en configuratiegemak. Elk pakket wordt vanaf het begin gedownload en gecompileerd met behulp van variabelen en configuratiebestanden.

The Bridge

Arch is gemaakt als een brug tussen een binaire distributie, zoals een van de 3 Major Parents, en een brongebaseerde distributie zoals een van de 3 minderjarige ouders. Als zodanig krijgt het de status als ouder in de tijdlijn, omdat geen enkele andere ouder deze functionaliteit heeft geleverd. Pacman heeft de flexibiliteit om een gebruiker toe te staan een binair pakket te installeren vanuit een officiële repository, of een op maat gemaakt pakket met behulp van het Arch Build-systeem. Dit concept biedt een balans tussen de kracht die de minderjarige ouders geven met het installatiegemak dat de grote ouders geven.

Naar mijn mening is het niet de pakketbeheerder die de kracht van een systeem, aangezien alle pakketbeheerders dezelfde taak uitvoeren, namelijk het beheren en onderhouden van een gezond systeem. Als zodanig moet het systeem dat u gebruikt worden bepaald door factoren zoals:

• Gebruikersniveau: iemand nieuw voor linux zou moeten beginnen met een Major Parent, terwijl iemand technisch bekwaam een balans zal vinden.
• Wat u met uw systeem wilt doen: het draaien van een LAMP-server met aangesloten gebruikers is totaal anders dan het draaien van een desktop-pc voor surfen op het web en het lezen van e-mail.
• Comfortniveau: niet-bestaand gebruikersniveau, als je technisch bekwaam bent, maar geen weekend wilt besteden aan het samenstellen van een systeem, kies je een belangrijke ouder, ongeacht of iedereen die je kent iets anders kiest.

Reacties

• Dit is meer gericht gebruikt op de geneaologie van de distributies, in plaats van een vergelijking van pacman en Debian ‘ s pakketbeheertools …
• @jasonwryan That ‘ is het punt, aangezien alle pakketbeheerders dezelfde taak uitvoeren, dwz emerge packagename is hetzelfde als sudo apt-get install packagename.
• Op dat niveau, ja; maar dat mist helemaal het punt van de vraag, dat wil zeggen, wat onderscheidt pacman van {apt, aptitude}.
• @jasonwryan Ik heb dat beantwoord in de sectie The Bridge. Behalve dat is er geen verschil. De enige verschillen zijn semantisch, d.w.z. het ene commando versus het andere.Als het OP op zoek is naar semantische verschillen, is daar een handleiding voor.

Dit is van nee betekent een volledig of uitputtend antwoord – de posters die voor mij liggen gaven al een aantal zeer goede punten, ik “zou gewoon mijn 2 cent willen toevoegen. Nog iets – ik ben nooit echt gewend geraakt aan apt / dpkg. Het leek altijd te ingewikkeld om ik, ik voel me echt het meest op mijn gemak met yum / rpm.

pacman is heel gemakkelijk te gebruiken, wat een pro en een nadeel is – je kunt het leren gebruiken (pakketopbouw terzijde) in een enkele middag – het gebruikt voornamelijk intuïtieve en complete functies voor pakketbeheer, maar – en dit is een grote maar – het is buitengewoon inflexibel.

Als de ontwerpers van tevoren niet aan een functie hebben gedacht, ben je verneukt.

Een paar voorbeelden: er is geen native versiebeheer in pacman. Als u een pakketversie wilt downgraden, moet u die specifieke pakketversie downloaden en de optie -U (upgrade) gebruiken om te installeren vanaf een bestand. is erg gericht op alwa ys met behulp van geavanceerde pakketten op uw systeem.

Er is geen echte interne cache-opschoning / volledige herbouw. Als (als gevolg van een netwerkprobleem) een pakketdownload beschadigd is, bijvoorbeeld tijdens -Syu, zal het foutbericht, hoewel juist, niet veel nuttig zijn – het zal het corrupte pakket niet lokaliseren, zelfs niet als “volledige” breedsprakigheid en foutopsporing zijn ingeschakeld , en geen enkele hoeveelheid -Syyc zal de cache echt opschonen en de pakketten opnieuw downloaden. Het goede nieuws is dat -Sc je laat weten waar de gedownloade pakketten zijn, zodat je eenvoudig de aanstootgevende kunt verwijderen (als je erachter kunt komen welke dat is) of allemaal en -Syu opnieuw kunt starten.

pacman-integratie met dkms is ook enigszins problematisch – tijdens het installeren van een nieuwe kernel bleef ik fouten krijgen van dkms. Het gebruik van dkms build & & dkms install tegen de nieuwe kernel werkte probleemloos, maar pacman bood geen enkele informatie waarom dkms faalde tijdens de kernel-upgrade (ik vermoed dat het nooit het juiste pad van de nieuwe kernel is gepasseerd, en laat dkms gewoon de standaard (huidige actieve) kernel gebruiken, maar met de verkeerde versie).

Nog een anekdote over de inflexibiliteit ervan – zoals zei, ik ben gewend aan toeren / jammeren. Als ik een bestand op mijn systeem heb en ik wil weten welk pakket het bezit, kan ik yum provid / path / to / file draaien en ALLE pakketten krijgen die het daar kunnen plaatsen – zelfs als geen van hen is geïnstalleerd. Als het bestand handmatig is geplaatst, en ik wil nu een pakket installeren, zal het het nieuwe hernoemen (extensie .rpmnew toevoegen), en mij laten kiezen wat ik wil gebruiken.

pacman geeft gewoon een foutmelding dat een bestand al is bestaat, maar met een volledig irrelevante foutmelding – het klaagt over conflicten tussen de “echte” eigenaar van het bestand en het momenteel geïnstalleerde “bestandssystemen” -pakket, alsof het ook een eigenaar is van hetzelfde bestand. Het is ook meestal gericht op lokaal geïnstalleerde informatie – het proberen om informatie te verkrijgen (zoals bestandslijsten en eigendom) van nog niet geïnstalleerde pakketten is minder intuïtief.

Simpel gezegd – het is niet zo volwassen als yum, en waarschijnlijk dpkg, wat ook aan zijn gebruiksgemak bijdraagt, is relatieve onbuigzaamheid.

Opmerkingen

• Kort van een alomvattend niet-antwoord, er zijn een aantal punten die u naar voren brengt die echt het gevolg zijn van een onbekendheid met pacman. pacman -Qo $file zal je bijvoorbeeld vertellen welk pakket $ file bezit. Ook is je hele antwoord een stroman, aangezien het OP expliciet om verschillen tussen Arch en Debian vroeg – yum heeft er niets mee te maken …
• daarom heb ik dat feit expliciet vermeld aan het begin van mijn antwoord. wat betreft het -Qo $ bestand – heb je dat ooit geprobeerd voor een pakket dat nog niet is geïnstalleerd?
• Het heeft geen zin om het te proberen voor een niet-geïnstalleerd pakket; daar zijn andere tools voor. En openbaarmaking vermindert niet ‘ het feit dat u ‘ t de vraag niet hebt beantwoord: a ” vergelijking ” tussen yum en pacman is niet hetzelfde als de verschillen tussen Debian ‘ s en Arch ‘ s pakketbeheerders.
• @jasonwryan Natuurlijk is er een punt. Alleen omdat je ‘ de noodzaak niet inziet om erachter te komen welk pakket een bestand zou kunnen bezitten, zelfs als het ‘ nog niet is geïnstalleerd, niet ‘ betekent dat een dergelijke behoefte niet ‘ bestaat. Dat was het punt. Wat betreft andere tools: zijn ze op een need-to-know-basis? pacman is de pakketbeheerder. Wat betreft je belangrijkste punt – ik heb de vraag misschien helemaal verkeerd gelezen, maar ik ging ervan uit dat het om een lichtgewicht PM gaat versus een meer complexe PM. Ik neem aan dat apt / dpkg minstens zo complex is als yum / rpm, qua eigenschappen.
• Mijn punt is dat je een vraag beantwoordt over het vergelijken van appels met peren door je beperkte begrip van appels met peren te vergelijken. En ja, je hebt de vraag helemaal verkeerd gelezen …