Въведение

А система за управление на пакети или мениджър на пакети е група от софтуерни инструменти. Той автоматизира процеса на инсталиране, процеса на надграждане, процеса на конфигуриране и процеса на премахване на компютърните програми за операционна система на компютъра по ефективен начин. А мениджър на пакети работи с пакети, данни в архивни файлове и софтуерни дистрибуции.

Пакетите включват метаданни като име на софтуера, описание на неговата цел, контролна сума (за предпочитане криптографска хеш функция), d списък на зависимостите, доставчик, и номер на версията от съществено значение за правилното функциониране на софтуера.

• Метаданните се записват в базата данни на локален пакет при инсталиране.
• Обикновено мениджърите на пакети управляват базата данни с информация за версията и софтуерните зависимости за предотвратяване на липсващи предпоставки и софтуерни несъответствия.
• Те работят в тясно сътрудничество с магазини за приложения, мениджъри на бинарни хранилища и софтуерни хранилища.
• Мениджърите на пакети са разработени за елиминиране на изискването за ръчни актуализации и инсталирания.
• По-специално, може да бъде полезно за големи организации, чиито операционни системи обикновено комбинират стотици или много повече различни софтуерни пакети.

Функции на Package Manager

Софтуерният пакет може да се дефинира като архивен файл комбиниране на компютърна програма и основни метаданни, както и за разработката. Системната програма може да бъде в изходния код, който първо трябва да бъде изграден и компилиран.

Метаданните на пакета съдържат версия на пакета, описание на пакета и зависимости (пакети, които трябва да бъдат инсталирани предварително). Много мениджъри на пакети са собственост на действието за инсталиране, деинсталиране, поддържане или намиране на софтуерни пакети под командването на потребителя.

The система за управление на пакети съдържа някои типични функции които са споменати по-долу:

• Работа с файловите архиватори за извличане на пакетни архиви.
• Гарантиране на автентичността и целостта на пакета чрез удостоверяване на техните цифрови сертификати и съответно контролни суми.
• Актуализиране, инсталиране, изтегляне или търсене на съществуващ софтуер чрез магазин за приложения или софтуерно хранилище.
• Комбиниране на пакети чрез функция за намаляване на объркването на потребителя.
• Поддържане на зависимости за гарантиране, че даден пакет е инсталиран заедно с всеки пакет, от който се нуждае. И така, игнориране „ад на зависимостта“.

Предни части за компилирани пакети (локално)

Системни администратори може да инсталира и управлява софтуера с помощта на някои инструменти, различни от софтуера за управление на пакети. Например, локален администратор може да изтегли изходния код (неопакован), да го компилира и след това да го инсталира.

Това може да доведе до изпадане на състоянието на локалната система от синхронизацията заедно с базата данни на състоянието на мениджъра на пакети. Локалният администратор ще трябва да предприеме някои допълнителни мерки като ръчно интегриране на модификациите в мениджър на пакети или управление на няколко зависимости.

centos срещу redhat

Има налични инструменти за гарантиране, че пакетите за компилиране (локално) са разработени с управлението на пакети.

CheckInstall е достъпен за .rpm или .deb файлови дистрибуции и Slackware Linux както добре. За хибрид системи като Arch Linux и системи, базирани на рецепти като Gentoo Linux, възможно е първоначално да се посочи рецепта, която след това потвърждава, че даден пакет се вписва в локална база данни за пакети.

Предизвикателства с разпределените библиотеки

Различни компютърни системи, които зависят от свързването на динамична библиотека, а не от свързване на статична библиотека, разпределят библиотеките с машинни инструкции (изпълними) между приложения и пакети.

В тези типове системи типичните връзки между различни пакети, нуждаещи се от библиотечни версии, водят до предизвикателство, наречено „ад на зависимостта“.

Известен е още като „DLL по дяволите“ на Microsoft Windows при динамична работа със свързани библиотеки. Доброто управление на пакети е от решаващо значение за тези системи.

от OPENSTEP , рамковата система беше опит за решаване на този проблем, като позволи едновременното инсталиране на повече от една версия на библиотеката и за много софтуерни пакети да описват коя версия са свързани.

Поддръжка на конфигурацията

Надстройките на конфигурационния файл са особено проблематични при софтуерни надстройки. Поне в Unix, тъй като мениджърите на пакети произхождат от разширението на помощната програма за архивиране на файлове.

Обикновено те само запазват или презаписват конфигурационните файлове, вместо да използват правила за тях. Няколко проблема могат да възникнат, когато форматът на конфигурационния файл се промени. Например, ако стар конфигурационен файл не деактивира изрично по-новите опции, това трябва да се покаже. Няколко мениджъра на пакети, като dpkg на Debian, позволяват конфигурация по време на инсталиране. В някои други случаи е желателно пакетите да се инсталират заедно с помощта на конфигурацията по подразбиране и да се презапише конфигурацията при инсталация (без глава) на голям брой системи. Този тип инсталация (предварително конфигурирана) се поддържа и чрез dpkg.

Потискане на надграждане

Традиционно е на разположение на потребителя заедно със списъка с действия, който трябва да се изпълни (обикновено списъкът с пакети за надграждане и евентуално предоставяне на номера на новата и старата версия), ако потребителят си сътрудничи със софтуера за управление на пакети за извършване на надстройката.

Позволява на потребителя да избере единичен пакет за надстройки или да вземе надстройка накуп. Различни мениджъри на пакети могат да бъдат конфигурирани никога да не надграждат много пакети или да ги надграждат само ако са открити критични нестабилности или уязвимости в стария стандарт, както е посочено от софтуерния пакет. Понякога този процес е известен като фиксиране на версия.

Например:

yum го поддържа с exclude=openoffice* синтаксис

pacman със синтаксиса Игнориране=openoffice (и в двата случая, за потискане на надграждането на openoffice)

dselect и dpkg го поддържат частично чрез флага за задържане в избраните пакети.

способността има 'забранявам' и 'задръж' знамена.

portage го поддържа чрез конфигурационен файл, т.е. опаковка.маска.

APT разширява флага, т.е. задръжте от комплекса 'закрепване' метод (потребителите могат да добавят и пакета в черен списък).

Хранилища

За да осигурят на потребителите допълнителен контрол върху типовете софтуер, които разрешават да бъдат инсталирани в тяхната система (понякога поради удобство и правни причини от страна на дистрибутора), софтуерът понякога се изтегля с помощта на много софтуерни хранилища.

оператор за остатък на python

Каскадно премахване на пакети

Няколко от по-развитите аспекти за управление на пакети улесняват „каскадно премахване на пакети“, където всеки пакет, който разчита на целевия пакет, и всеки пакет, на който разчита целевият пакет, също се премахват.

Сравнение на команди

Командите обаче са уникални за всички конкретни мениджъри на пакети. Тези команди са до голяма степен преводими, тъй като повечето от мениджърите на пакети улесняват същите функции.

Разпространение на пакетния мениджър

Мениджъри на пакети като dpkg са налични още през 1994 г. Различни дистрибуции на Linux, ориентирани към двоичните пакети, силно разчитат на системата за управление на пакети поради основното им средство за поддръжка и управление на софтуера.

Много мобилни операционни системи като Windows Phone, iOS (подобни на Unix) и Android (базирани на Linux) зависят почти от съответния App Store на доставчика. Следователно те използват своята система за управление на пакети (посветена).

Сравнение с инсталаторите

Често мениджърът на пакети е известен като „инсталационен мениджър“. Това може да предизвика объркване сред инсталаторите и мениджърите на пакети. Някои от основните разлики са дадени по-долу:

Сравнение с помощната програма за автоматизация

Почти всички системи за управление на конфигурацията на софтуера представляват софтуер за внедряване и софтуер за изграждане като отделни. Обикновено помощната програма за автоматизиране на изграждането взема файловете с изходен код, които са в четим от човека формат, вече в дадена система, и ускорява процедурата по преобразуването им в изпълним пакет (двоичен) на подобна система.

Обикновено мениджърът на пакети, който по-късно работи на няколко други системи, изтегля тези изпълними пакети (предварително изградени двоични) в Интернет и след това ги инсталира.

Въпреки това и двата вида инструменти включват няколко общи фактора, които са споменати по-долу:

• Топологичното сортиране на графиката на зависимостта се прилага в рамките на мениджър на пакети за обработка на зависимости между много двоични компоненти.
• Също така, той се прилага вътре в мениджър за изграждане за справяне със зависимостта между много компоненти на източника.
• Различни makefiles осигуряват тяхната поддръжка, а не само изграждане на изпълними файлове.
• Освен това те поддържат инсталирането на, като се използва make install.
• Всички мениджъри на пакети поддържат превод на изходния код (четим от човека) в двоични изпълними файлове и след това го инсталират за базирана на изходен код дистрибуция като Homebrew, Sorcery, Portage и др.

Някои инструменти като А-А-П и направи са разработени да управляват както внедряването, така и изграждането. Те могат също да се използват като мениджър на пакети или помощна програма за автоматизиране на изграждането, или и двете.

Основни пакетни мениджъри и техните формати

Универсален мениджър на пакети

Нарича се още мениджър на бинарно хранилище. Този мениджър на пакети е софтуерен инструмент, създаден за оптимизиране на съхранението и изтеглянето на двоични файлове, пакети и артефакти, произведени и използвани в рамките на процес на разработка на софтуер.

Универсални пакетни мениджъри съсредоточете се върху стандартизирането на отношението на модните потребители към всеки тип опаковка. Те предоставят на потребителите възможността да използват показатели за съответствие и сигурност около всеки тип артефакт. Те са определени като намиращи се в средата на a Инструментална верига DevOps.

Системи с отворен код и безплатен софтуер

Пакетите при съвместими и подобни лицензи са съществували за използване на няколко операционни системи чрез поведението на софтуер с отворен код и безплатен софтуер.

Тези пакети могат да се разпространяват и комбинират с помощта на вътрешно сложни и конфигурируеми системи за пакетиране за управление на няколко специфични за версията конфликти и зависимости и софтуерни пермутации.

Също така, няколко системи за опаковане на софтуер с отворен код и безплатен софтуер сами по себе си се публикуват като софтуер с отворен код и безплатен софтуер.

Една разлика между управлението на пакети в операционни системи като Windows и Mac OS X и тези в софтуер с отворен код и безплатен софтуер като Linux е, че системите с отворен код и безплатния софтуер позволяват пакети на трети страни да бъдат надграждани и инсталирани от подобен механизъм . Като има предвид, че много мениджъри на пакети на Windows и Mac OS X ще надстроят софтуера, предоставен съответно от Microsoft и Apple.

Възможността за непрекъснато надграждане на софтуер на трета страна се добавя чрез включване на съответния URL адрес на хранилището към конфигурационния файл на управлението на пакети.

Формати на пакети

Всички мениджъри на пакети зависят от метаданните и формата на пакетите, които могат да управляват. Мениджърите на пакети изискват групите файлове да бъдат групирани за конкретния мениджър на пакети с подходящи метаданни като зависимости.

Основна колекция от помощни програми често управлява общата инсталация чрез тези пакети и повече от един мениджър на пакети прилага тези помощни програми за осигуряване на допълнителна функционалност.

Пример:

1. yum зависи от rpm като бекенд. Yum развива функционалността на бекенда, като добавя аспекти като проста конфигурация за поддържане на системната мрежа.
2. Синаптичният мениджър на пакети предоставя GUI чрез прилагане на библиотеката на Advanced Packaging Tool, която зависи от dpkg.

Извънземно може да се дефинира като програма, която превежда между отделни Linux пакетни формати. Поддържа преобразуване сред Slackware (.tgz, .tlz, .tbz, .txz) пакети, Solaris (.pkg), Stampede (.slp), .deb, .rpm пакети, и Стандартна база на Linux (LSB) съвместим.

В няколко мобилни операционни системи, като напр Google Play използва пакетния формат на Пакет приложения за Android (накратко APK ) докато Windows Store използва форматите на XAP и ПРИЛОЖЕНИЕ. И двете Windows Store и Google Play съдържат едноименни мениджъри на пакети.

Мениджъри на пакети на ниво приложение

Има няколко мениджъра на пакети (добавка) за операционни системи за езици за програмиране и с ограничени възможности, където разработчиците изискват текущите библиотеки. Мениджърите на пакети на ниво приложение се концентрират върху малката част от софтуерната система за разлика от мениджърите на пакети на системно ниво.

Обикновено те се намират в дърво на директория. Не е организиран от мениджър на пакети на системно ниво като /usr/local/fink или c:cygwin. Въпреки че може да не е условието за мениджър на пакети, който работи с програмни библиотеки, причинявайки възможен конфликт, тъй като и двата мениджъра на пакети могат да прекъснат надстройките и да поискат 'собствен' файлът.