Invoering
A pakketbeheersysteem of pakketbeheerder is een groep softwaretools. Het automatiseert het installatieproces, het upgradeproces, het configuratieproces en het verwijderingsproces van de computerprogramma's voor een besturingssysteem van de computer op een efficiënte manier. A pakket manager werkt met pakketten, gegevens in archiefbestanden en softwaredistributies.
Pakketten bevatten metagegevens zoals de naam van de software, beschrijving van het doel, controlesom (bij voorkeur een cryptografische hashfunctie), d afhankelijkheidslijst, leverancier, En versienummer essentieel voor het goed functioneren van de software.
- Metagegevens worden tijdens de installatie opgeslagen in de database van een lokaal pakket.
- Doorgaans beheren pakketbeheerders de database met versie-informatie en software-afhankelijkheden om ontbrekende vereisten en software-mismatches te voorkomen.
- Ze werken nauw samen met appstores, beheerders van binaire repository's en softwarerepository's.
- Pakketbeheerders zijn ontwikkeld om de noodzaak van handmatige updates en installaties te elimineren.
- Het kan met name nuttig zijn voor grote organisaties waarvan de besturingssystemen doorgaans honderden of veel meer verschillende softwarepakketten combineren.
Functies van Pakketbeheerder
Een softwarepakket kan worden gedefinieerd als het archiefbestand het combineren van een computerprogramma en essentiële metadata, ook voor de ontwikkeling. Het systeemprogramma kan zich in de broncode bevinden die eerst moet worden gebouwd en gecompileerd.
Metagegevens van pakketten bevatten de pakketversie, pakketbeschrijving en afhankelijkheden (pakketten die vooraf moeten worden geïnstalleerd). Veel pakketbeheerders zijn verantwoordelijk voor het installeren, verwijderen, onderhouden of vinden van softwarepakketten onder het commando van de gebruiker.
De pakketbeheersysteem bevat enkele typische functies die hieronder worden vermeld:
- Omgaan met de bestandsarchiveraars voor het extraheren van pakketarchieven.
- Het garanderen van de authenticiteit en integriteit van het pakket door respectievelijk hun digitale certificaten en controlesommen te authenticeren.
- Bestaande software bijwerken, installeren, downloaden of opzoeken via een app store of softwarerepository.
- Pakketten combineren via functie om de verwarring bij de gebruiker te verminderen.
- Het onderhouden van afhankelijkheden om ervoor te zorgen dat een pakket is geïnstalleerd samen met elk pakket dat het nodig heeft. Negeren dus 'afhankelijkheidshel'.
Front-ends voor gecompileerde pakketten (lokaal)
Systeembeheerders kan de software installeren en beheren met behulp van andere tools dan de software voor pakketbeheer. Bijvoorbeeld, een lokale beheerder kan de broncode downloaden (uitgepakt), compileren en vervolgens installeren.
Het kan ervoor zorgen dat de lokale systeemstatus buiten de synchronisatie valt, samen met de database van de pakketbeheerderstatus. De lokale beheerder zou een aantal aanvullende maatregelen moeten nemen, zoals het handmatig integreren van de wijzigingen in een pakketbeheerder of het beheren van een paar afhankelijkheden.
waar vind ik mijn browserinstellingen
Er zijn enkele tools aanwezig om ervoor te zorgen dat de compileerpakketten worden gecompileerd (lokaal) zijn ontwikkeld met pakketbeheer.
ControleerInstalleren is beschikbaar voor .rpm of Op .deb-bestanden gebaseerde distributies En Slackware-Linux ook. Voor hybride systemen zoals Boog Linux En receptgebaseerde systemen leuk vinden Gentoo Linux, het is mogelijk om in eerste instantie een recept op te geven, dat vervolgens bevestigt dat een pakket in een lokale pakketdatabase past.
Uitdagingen met gedistribueerde bibliotheken
Verschillende computersystemen die afhankelijk zijn van de dynamische bibliotheekkoppeling, in plaats van de statische bibliotheekkoppeling, distribueren de (uitvoerbare) bibliotheken van machine-instructies over applicaties en pakketten.
In dit soort systemen worden de typische relaties tussen verschillende pakketten die bibliotheekversies nodig hebben, in een uitdaging genoemd 'afhankelijkheidshel'.
Het is ook bekend als 'DLL-hel' op Microsoft Windows bij het dynamisch omgaan met gekoppelde bibliotheken. Voor deze systemen is goed pakketbeheer cruciaal.
Van OPENSTAP , was het raamwerksysteem een poging om dit probleem op te lossen, door het mogelijk te maken dat meer dan één bibliotheekversie tegelijkertijd werd geïnstalleerd, en door voor veel softwarepakketten te beschrijven aan welke versie ze zijn gekoppeld.
Configuratie Onderhoud
De upgrades van het configuratiebestand zijn vooral problematisch bij software-upgrades. In ieder geval op Unix, aangezien pakketbeheerders hun oorsprong vonden als de extensie voor het archiveren van bestanden.
Meestal behouden of overschrijven ze alleen de configuratiebestanden, in plaats van er regels voor te gebruiken. Er kunnen verschillende problemen optreden wanneer het configuratiebestandsformaat verandert. Als een oud configuratiebestand bijvoorbeeld nieuwere opties niet expliciet uitschakelt, moeten deze worden weergegeven. Een paar pakketbeheerders, zoals dpkg van Debian, staan configuratie toe op het moment van installatie. In sommige andere gevallen is het wenselijk om pakketten te installeren met gebruikmaking van de standaardconfiguratie en de configuratie tijdens de installatie (headless) te overschrijven naar een groot aantal systemen. Dit type installatie (vooraf geconfigureerd) wordt ook ondersteund via dpkg.
Onderdrukking van upgrades
Het is traditioneel om de gebruiker samen met de uit te voeren actielijst ter beschikking te stellen (meestal de pakketlijst die moet worden geüpgraded en eventueel de nieuwe en oude versienummers te verstrekken) als een gebruiker samenwerkt met de pakketbeheersoftware om de upgrade tot stand te brengen.
Hiermee kan de gebruiker een enkel pakket voor upgrades selecteren of een upgrade in bulk nemen. Er kunnen verschillende pakketbeheerders worden geconfigureerd om nooit veel pakketten te upgraden, of om ze alleen te upgraden als er kritieke instabiliteiten of kwetsbaarheden worden gedetecteerd in de oude standaard, zoals gespecificeerd door het softwarepakket. Soms staat dit proces bekend als versie vastzetten.
Bijvoorbeeld:
yum ondersteunt het met de uitsluiten=openoffice* syntaxis
pacman met de syntaxis Negeren=openoffice (in beide gevallen, voor het onderdrukken van het upgraden van openoffice)
dselect en dpkg ondersteunen dit gedeeltelijk door de hold-vlag binnen de pakketselecties.
geschiktheid heeft 'verbieden' En 'uitstel' vlaggen.
portage ondersteunt het door een configuratiebestand, d.w.z. pakket.masker.
APT breidt de vlag uit, d.w.z. uitstel door het complex 'vastzetten' methode (gebruikers kunnen het pakket ook op de zwarte lijst zetten).
Opslagplaatsen
Om gebruikers extra controle te geven over de soorten software die ze op hun systeem mogen installeren (soms vanwege het gemak en juridische redenen van de kant van de distributeur), wordt de software soms gedownload via veel softwarebronnen.
boto3
Trapsgewijze verwijdering van pakketten
Een paar van de meer ontwikkelde aspecten van pakketbeheer vergemakkelijken dit 'trapsgewijze pakketverwijdering', waarbij elk pakket dat afhankelijk is van het bestemmingspakket en elk pakket waarvan het doelpakket afhankelijk is, ook worden verwijderd.
Vergelijking van opdrachten
De opdrachten zijn echter uniek voor alle specifieke pakketbeheerders. Deze commando's zijn voor een groot deel vertaalbaar omdat de meeste pakketbeheerders dezelfde functies faciliteren.
Prevalentie van de pakketbeheerder
Pakketbeheerders zoals dpkg zijn al in 1994 beschikbaar. Verschillende Linux-distributies die op de binaire pakketten zijn gericht, zijn sterk afhankelijk van het pakketbeheersysteem vanwege hun belangrijkste manier om software te onderhouden en te beheren.
Veel mobiele besturingssystemen zoals Windows Phone, iOS (Unix-achtig) en Android (Linux-gebaseerd) zijn bijna afhankelijk van hun respectievelijke App Store van de leverancier. Daarom gebruiken ze hun pakketbeheersysteem (dedicated).
Vergelijking met de installateurs
Vaak staat een pakketbeheerder bekend als een 'installatiemanager'. Het kan verwarring veroorzaken onder installateurs en pakketbeheerders. Enkele van de belangrijkste verschillen worden hieronder gegeven:
| Criterium | Pakket manager | Installateur |
|---|---|---|
| Verzonden met | Meestal het besturingssysteem | Alle computerprogramma's |
| Locatie van installatie-informatie | Een centrale database voor installatie | Dit is volledig ter beoordeling van de installateur. Het kan een bestand zijn in de map van de app of tussen de mappen en bestanden van het besturingssysteem. Ze kunnen zichzelf registreren op de lijst van een verwijderprogramma zonder de installatie-informatie vrij te geven. |
| Onderhoudsbereik | Potentieel elk pakket op een systeem | Alleen het product waarin het verpakt was |
| Ontwikkelaar | Leverancier van één pakketbeheerder | Meer dan één installateurleverancier |
| Formaat van pakket | Een handvol erkende formaten | Er kunnen zoveel formaten zijn als het nummer van de app |
| Compatibiliteit van pakketformaat | Kan worden gebruikt zolang een pakketbeheerder het gebruikt. Ofwel upgradet de gebruiker een pakketbeheerder niet, ofwel blijven de nieuwe pakketbeheerderversies dit ondersteunen. | Als het installatieprogramma een archiefformaat gebruikt, is het installatieprogramma er altijd compatibel mee. Hoewel installatieprogramma's, zoals elke computer, kunnen worden beïnvloed door softwarerot. |
Vergelijking met automatiseringshulpprogramma
Bijna alle softwareconfiguratiebeheersystemen vertegenwoordigen het implementeren van software en het bouwen van software als afzonderlijke systemen. Doorgaans neemt het hulpprogramma voor bouwautomatisering de broncodebestanden die zich in een door mensen leesbaar formaat bevinden al op een systeem en versnelt het de procedure van het converteren ervan naar een uitvoerbaar pakket (binair) op een soortgelijk systeem.
Normaal gesproken downloadt een pakketbeheerder die later op een paar andere systemen draait, die uitvoerbare pakketten (vooraf gebouwd binair bestand) op internet en installeert ze vervolgens.
Beide soorten tools bevatten echter verschillende gemeenschappelijke factoren, die hieronder worden vermeld:
- De topologische sortering van de afhankelijkheidsgrafiek wordt toegepast binnen een pakketbeheerder voor het afhandelen van afhankelijkheden tussen veel binaire componenten.
- Het wordt ook toegepast binnen een buildmanager voor het afhandelen van de afhankelijkheid tussen veel broncomponenten.
- Verschillende makefiles bieden hun ondersteuning, niet alleen het bouwen van uitvoerbare bestanden.
- Ze ondersteunen ook het installeren van het programma, met behulp van make install.
- Alle pakketbeheerders ondersteunen het vertalen van de broncode (voor mensen leesbaar) naar binaire uitvoerbare bestanden en installeren deze vervolgens voor de brongebaseerde distributie zoals Homebrew, Sorcery, Portage, enz.
Sommige hulpmiddelen zoals A-A-P En Maken zijn ontwikkeld om zowel de implementatie als de bouw te beheren. Ze kunnen ook worden gebruikt als pakketbeheerder of als hulpprogramma voor build-automatisering, of beide.
Basispakketbeheerders en hun formaten
Universele pakketbeheerder
Het wordt ook wel genoemd binaire repositorybeheerder. Deze pakketbeheerder is een softwaretool die is gemaakt voor het optimaliseren van de opslag en het downloaden van de binaire bestanden, pakketten en artefacten die worden geproduceerd en gebruikt binnen een softwareontwikkelingsproces.
Universele pakketbeheerders focus op het standaardiseren van de manier waarop gebruikers elk type pakket behandelen. Ze bieden gebruikers de mogelijkheid om compliance- en beveiligingsstatistieken voor elk type artefact te gebruiken. Ze zijn toegewezen als zijnde midden in een DevOps-toolchain.
Open-source en gratis softwaresystemen
De pakketten met compatibele en vergelijkbare licenties bestaan voor gebruik op verschillende besturingssystemen door het gedrag van open-source en vrije software.
Deze pakketten kunnen worden gedistribueerd en gecombineerd met behulp van intern complexe en configureerbare verpakkingssystemen om verschillende versiespecifieke conflicten, afhankelijkheden en softwarepermutaties te beheren.
Ook worden enkele verpakkingssystemen van open-source en vrije software zelf gepubliceerd als open-source en vrije software.
Een verschil tussen pakketbeheer in besturingssystemen zoals Windows en Mac OS X en die in open-source en vrije software, zoals Linux, is dat open-source en vrije softwaresystemen het mogelijk maken dat pakketten van derden via een soortgelijk mechanisme worden geüpgraded en geïnstalleerd. . Terwijl veel pakketbeheerders van Windows en Mac OS X software van respectievelijk Microsoft en Apple zullen upgraden.
De mogelijkheid om voortdurend software van derden te upgraden wordt toegevoegd door de overeenkomstige repository-URL op te nemen in het configuratiebestand van het pakketbeheer.
Pakketformaten
Alle pakketbeheerders zijn afhankelijk van de metadata en het formaat van de pakketten die ze kunnen beheren. Pakketbeheerders vereisen dat bestandsgroepen worden gegroepeerd voor de specifieke pakketbeheerder met de juiste metagegevens zoals afhankelijkheden.
Een kernverzameling hulpprogramma's beheert vaak de algemene installatie via deze pakketten en meer dan één pakketbeheerder past deze hulpprogramma's toe om extra functionaliteit te bieden.
Voorbeeld:
- yum hangt af van het toerental als de backend. Yum ontwikkelt de backend-functionaliteit door aspecten toe te voegen zoals eenvoudige configuratie om het systeemnetwerk te onderhouden.
- De synaptische pakketbeheerder geeft een GUI door de bibliotheek van de Advanced Packaging Tool toe te passen die afhankelijk is van de dpkg.
Buitenaards wezen kan worden gedefinieerd als een programma dat vertaalt tussen verschillende Linux-pakketformaten. Het ondersteunt de conversie onder Slackware (.tgz, .tlz, .tbz, .txz) pakketjes, Solaris (.pkg), Stampede (.slp), .deb, .rpm-pakketten, En Linux standaardbasis (LSB)-compatibel.
In verschillende mobiele besturingssystemen zoals Google Spelen maakt gebruik van het pakketformaat van de Android-applicatiepakket (Kortom APK ) Terwijl de Windows Store gebruikt de formaten van XAP En APPX. Beide Windows Store En Google Spelen bevatten gelijknamige pakketbeheerders.
Pakketbeheerders op applicatieniveau
Er zijn een paar pakketbeheerders (add-on) voor besturingssystemen voor programmeertalen en met beperkte mogelijkheden, waarbij ontwikkelaars de huidige bibliotheken nodig hebben. De pakketbeheerders op applicatieniveau concentreren zich op het kleine deel van het softwaresysteem, in tegenstelling tot de pakketbeheerders op systeemniveau.
Normaal gesproken bevinden ze zich in een directorystructuur. Het wordt niet georganiseerd door een pakketbeheerder op systeemniveau, zoals /usr/local/fink of c:cygwin. Hoewel dit misschien niet de voorwaarde is voor een pakketbeheerder die met programmeerbibliotheken werkt, kan dit een mogelijk conflict veroorzaken omdat beide pakketbeheerders upgrades kapot kunnen maken en verzoeken om 'eigen' het bestand.