Et programvarelager er et lagringssted hvorfra programvarepakker kan hentes og installeres på en datamaskin.
Mange programvareutgivere og andre organisasjoner vedlikeholder servere på Internett for dette formålet, enten gratis eller mot et abonnementsgebyr. Lagre kan kun være for bestemte programmer, for eksempel CPAN for programmeringsspråket Perl , eller for et helt operativsystem . Operatørene av disse depotene tilbyr ofte et pakkehåndteringssystem , verktøy beregnet på å finne, installere og manipulere programvarepakkene fra depotene. For eksempel bruker mange Linux-distribusjoner Advanced Packaging Tool (APT), som vanligvis finnes i Debian -baserte distribusjoner., eller nam , funnet i Red Hat - baserte distribusjoner . Det finnes også flere uavhengige pakkehåndteringssystemer, for eksempel pacman, brukt i Arch Linux , og Equo, funnet i Sabayon Linux .
Akkurat som programvarelager er designet for å inkludere nyttige pakker, er viktige depoter designet for å være fri for skadelig programvare . Hvis en datamaskin er konfigurert til å bruke en digital signatur fra et pålitelig leverandørlager, kombinert med et riktig tillatelsessystem, reduserer det trusselen for skadelig programvare på disse systemene betydelig. Som en bieffekt krever mange systemer som har disse egenskapene ikke antivirusprogramvare eller anti-malware-programvare.
De fleste store Linux-distribusjoner har mange depoter rundt om i verden som speiler hovedlageret.
Et pakkehåndteringssystem er forskjellig fra en pakkeutviklingsprosess.
En typisk bruk av et pakkehåndteringssystem er å lette integrasjonen av kode fra muligens ulike kilder til en sammenhengende og uavhengig driftsenhet. Dermed kan et pakkehåndteringssystem brukes til å produsere en Linux-distribusjon , muligens en distribusjon skreddersydd for en spesifikk begrenset applikasjon.
En pakkeutviklingsprosess, derimot, brukes til å administrere samutvikling av kode og dokumentasjon for en samling funksjoner eller rutiner med et felles tema, og dermed produsere et sett med programvarefunksjoner som normalt ikke vil være komplette og brukbare. alene. En god pakkeutviklingsprosess vil hjelpe brukere, i samsvar med god dokumentasjon og kodingspraksis, med integrering av et visst nivå av enhetstesting . Tabellen nedenfor gir eksempler på pakkeutviklingsprosesser.
Følgende tabell viser et par språk med depotene for tilført programvare. Kolonnen "Autosjekker" beskriver rutinekontrollene som er utført.
Svært få mennesker har muligheten til å teste programvaren sin på flere operativsystemer med forskjellige versjoner av kjernekoden og med andre bidragspakker som de kan bruke. For R , Comprehensive R Archive Network (CRAN), utfører rutinemessig tester. For å se hvor verdifullt dette er, la oss anta at Sally bidrar med pakke A. Bare Sally kjører gjeldende versjon av programvaren på en versjon av Microsoft Windows og har kun blitt testet i det miljøet. Med mer eller mindre jevne mellomrom tester CRAN Sallys bidrag på et dusin kombinasjoner av operativsystemer og versjoner av kjerneprogramvaren til språket R. Hvis en av dem genererer en feil, blir den feilmeldingen lagt ut. Forhåpentligvis kan den feilmeldingen være nok til at hun kan fikse feilen, selv om hun ikke kan replikere den med maskinvaren og programvaren hun har. Anta deretter at John bidrar med en pakke B som bruker pakke A til depotet. Pakke B består alle tester og gjøres tilgjengelig for brukere. Sally kommer senere med en forbedret versjon av A, som dessverre bryter B. Autosjekkene gjør det mulig å gi informasjon til John slik at han kan fikse problemet.
Dette eksemplet avslører både en styrke og en svakhet i R-bidragspakkesystemet: CRAN gir denne typen automatisert testing av bidratte pakker, men pakker som er bidratt til CRAN trenger ikke å spesifisere versjonene av andre bidragspakker som de bruker. Det finnes prosedyrer for å be om spesifikke versjoner av pakker, men bidragsytere vil ikke kunne bruke disse prosedyrene.
Utover dette kjører et depot som CRAN regelmessige kontroller av innsendte pakker, og tilbyr faktisk et omfattende sett med tester for kjerneutviklingsversjoner av språket. Hvis Sally (i eksempelet ovenfor) får en feilmelding som hun ikke forstår eller mener er upassende, spesielt fra en utviklingsversjon av språket, kan hun (og gjør det ofte med R) be hovedutviklingsteamet om hjelp til å fikse det. språket. På denne måten kan depotet bidra til å forbedre kvaliteten på språkets kjerneprogramvare.
| Formål / med språk | Pakkehåndteringsprosess | Oppbevaringssted | hvordan installere | Samarbeidsutviklingsplattform | egensjekker |
|---|---|---|---|---|---|
| C++ | Impuls | ||||
| Haskell | Felles arkitektur for byggeapplikasjoner og biblioteker (CABAL) | hacking | |||
| Java | Maven | ||||
| . nett | NuGet | NuGet | |||
| Node.js | NPM | ||||
| Perle | CPAN | ||||
| PHP | PECL | ||||
| python | oppsettverktøy | P&IP | pip , EasyInstall, PyPM | ||
| R | R CMD-sjekkprosess [ 1 ] [ 2 ] | CRAN | install.pakker | R-Forge | Omtrent ukentlig på 12 plattformer eller kombinasjoner av forskjellige versjoner av R (devel, prerel, patched, release) med opptil 7 forskjellige operativsystemer (ulike versjoner av Linux, Windows og Mac) |
| bioleder | Bioklit . R [1] | ||||
| Rubin | rubygems | Ruby Application Archive | RubyForge | ||
| TeX , LATEX | CTAN |
(Deler av denne tabellen ble kopiert fra [ 3 ] )
Programvare for å administrere depoter (repository managers) inkluderer: