Paketverwaltung


aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von Paketmanagement)
Wechseln zu: Navigation, Suche
Datei:Yum-update.png
YUM spielt Updates auf einem Fedora 16-System ein.
Datei:Debian-aptitude.png
aptitude mit Kommandozeilenbefehlen auf Debian
Datei:Aptitude 0.4.11.3 de.png
aptitude bietet auch eine TUI
Datei:Synaptic Package Manager.png
Synaptic unter Ubuntu
Datei:Kpackagekit.png
PackageKit ist eine grafische Oberfläche für verschiedene Paketverwaltungen, hier auf einem RHEL 6-System.
Datei:Ubuntu-Software Center.png
Das Ubuntu Software Center ist eine grafische Oberfläche für dpkg/APT, steht unter der GPL und ist nicht nur unter Ubuntu verfügbar

Eine Softwarepaket-Verwaltung (englisch package management software) ermöglicht die komfortable Verwaltung von Software, die in Programmpaketform vorliegt, auf einem Betriebssystem. Dazu gehören das Installieren, Aktualisieren und Deinstallieren.

Arbeitsweise

Voraussetzung für Paket-Management ist, dass die zu installierende Software als entsprechendes Paket vorliegt, typischerweise wird dies von dem Betriebssystemanbieter, unter Linux den Distributionen, zentral erstellt, angeboten und gepflegt. Software wird dadurch typischerweise direkt in das System und dessen verschiedene Funktionsverzeichnise verteilt integriert. Änderungen, welche die Paketverwaltung zur Installation des Pakets am System vornehmen muss, werden von dieser aus dem Paket ausgelesen und umgesetzt. Erkennt die Paketverwaltung dabei, dass noch weitere Software für das Funktionieren benötigt wird (sogenannte Abhängigkeit, z. B. eine Programmbibliothek), aber noch nicht installiert ist, warnt sie entweder oder versucht, die fehlende Software mit den ihr zur Verfügung stehenden Mitteln, z. B. aus einem Repository, nachzuladen und vorweg zu installieren.

Soll eine installierte Software gelöscht werden, nimmt die Paketverwaltung dann wieder die Informationen des Pakets, um es anhand dessen Konfiguration zu ändern und Dateien zu löschen.

Eigenschaften

Mit einer Paketverwaltung vereinfacht sich die Installation eines Programms erheblich, da Programme nicht erst einzeln heruntergeladen, kompiliert und installiert werden müssen. Außerdem überwachen die meisten Paketverwaltungen Konflikte zwischen Paketen mit gleichen Inhalten und verhindern so eine Systeminstabilität in dieser Beziehung.

Ebenso ist das Löschen von Software deutlich vereinfacht: Da die Paketverwaltung sich alle zu einem Paket gehörende Software merkt, kann bei einem Löschen eines Paketes sämtliche nicht mehr benötigte Software mit entfernt werden.

Definitionsüberschneidung

Es gibt genau genommen zwei Arten von Paketverwaltungen: Auf der einen Seite stehen die Programme, die aus anderen Quellen Pakete nachladen können, um Abhängigkeiten aufzulösen, auf der anderen Seite diejenigen Programme, die direkt die Pakete installieren oder löschen, aber keine Abhängigkeitsverwaltungs- und Konfliktlösungsmechanismen kennen.

Zwei konkrete Fälle: Das Programm RPM kann Pakete vom Typ *.rpm installieren und löschen, das Programm Dpkg kann Pakete vom Typ *.deb installieren und löschen. Beide können aber keine Abhängigkeiten auflösen, da sie keine Funktionen haben, um Software nachzuladen. Dies können höhere Schichten der Paketverwaltungen wie YUM, APT, pkg-get und andere.

Aufbau der Pakete

Ein Paket enthält neben den reinen Programmdateien auch Informationen, wo diese Programmdateien abgelegt werden sollen, welche Konfigurationen am bestehenden System vorgenommen werden müssen, und meist auch, ob und wenn, welche Software noch zusätzlich benötigt wird, damit das Programm funktioniert. Bei der Installation werden die Programmdateien im Paket in das laufende oder zu installierende System hinein entpackt, danach werden die Installationsskripte ausgeführt.

Es gibt mehrere konkurrierende Paketformate, die von unterschiedlichen Paketverwaltungen verarbeitet werden. Die wichtigsten sind:

  • pkgadd (und weitere Programme) die 1984 von AT&T für Unix eingeführte Paketverwaltung
  • RPM Package Manager (RPM), bei Red Hat, Fedora, Mandriva, OpenSUSE etc. verwendet
  • Debian Package Manager (dpkg) mit .deb-Dateien, bei Debian und Derivaten (z. B. Ubuntu) zu finden
  • Slackware verwendet Pakete, die im Archivierungsformat TGZ (tar.gz) und (seit Slackware 13) TXZ (tar.xz) gepackt werden, gern als Tarball bezeichnet
  • MSI − Installationsskript für Windows
  • Portage bei Gentoo
  • Package (.pkg) und Metapackage (.mpkg) für Mac OS X
  • FreeBSD und OpenBSD benutzen sowohl BSD-Ports, also Makefiles, die den gesamten Build-Prozess vom Herunterladen des Quellcodes bis zum Installieren enthalten, als auch Binärpakete im tar.gz-Format.
  • ipkg ist ein Format für Computer mit wenigen Ressourcen (z. B. WLAN-Router) u. a. von OpenWrt verwendet
  • NuSpec (.nuspec) ist ein Format für NuGet-Pakete<ref>Nuspec Reference. Abgerufen am 7. August 2013 (english, NuGet-Dokumentation für NuSpec-Pakete).</ref>

Paketerstellung

Pakete zu erstellen ist nicht trivial. Auch in kleinen Projekten gibt es meistens einen Packager, der dafür verantwortlich ist, dass Pakete funktionieren.

Der Packager nimmt die Programmquellen und trägt in einer Datei ein, welche Programme zur Kompilierung benötigt werden. Dann erstellt er Regeln, wie sich das Programm automatisiert kompilieren lässt. Außerdem sammelt und schreibt er Patches, welche automatisch eingespielt werden, und schreibt eine kurze Beschreibung des Pakets.

Das fertige Quellpaket kann nun automatisch für die gewünschte Plattform vorkompiliert werden.

Besondere Pakete

Zu beachten ist, dass bei einigen Linux-Distributionen viele Pakete zweimal vorkommen. Dabei handelt es sich beim zweiten Eintrag um das eigentliche Paket mit einem nachgestellten dev oder devel. Diese Abkürzung steht dabei für Development (englisch für Entwicklung), was darauf hinweist, dass dort Dateien enthalten sind, die für das Funktionieren des Programms nicht wichtig sind, aber gebraucht werden, wenn man darauf aufbauend weitere Software entwickeln will.

Vor- und Nachteile

Paketverwaltungen werden als einer der großen Vorteile und Erfolge der unixoiden Betriebssysteme beschrieben, z. B. von Ian Murdock als „the single biggest advancement Linux has brought to the industry“.<ref>Ian Murdock: How package management changed everything (englisch) ianmurdock.com. 21. Juli 2007. Abgerufen am 1. März 2008.</ref> Eine weitere typische Eigenschaft dieser ist jedoch auch die Verwischung der Grenzen zwischen Anwendungen und Betriebssystem durch die integrierte Verwaltung durch die Distributionen, d. h. das Betriebssystem agiert nicht als Plattform für Anwendungen, sondern beinhaltet diese.<ref name="tonymobilyinstallation">Tony Mobily: 2009: software installation in GNU/Linux still broken and a path to fixing it (englisch) www.freesoftwaremagazine.com. 23. Juni 2009. Abgerufen am 23. März 2010: „Every GNU/Linux distribution at the moment (including Ubuntu) confuses system software with end user software, whereas they are two very different beasts which should be treated very, very differently.“</ref><ref name="smedberg">Benjamin Smedberg: Is Ubuntu an Operating System? (englisch) 4. Oktober 2006. Abgerufen am 20. Januar 2012: „Ubuntu isn’t trying to be a platform for mass-market application software: it is trying to be the primary provider of both the operating system and all the application software that a typical user would want to run on his machine. Most Linux distributions are like this, and I think it is a dangerous trend that will stifle innovation and usability, or even worse make the desktop irrelevant.“</ref> Einerseits ist mit einem systemweiten Paketmanagement ein konfliktfreier Betrieb (ohne Bibliotheks-Konflikte) des Betriebssystems mit den Applikationen sichergestellt, anderseits wird eine direkte Verteilung von Anwendungssoftware durch den Entwickler an die Kunden schwieriger<ref name="brockmeier">Joe Brockmeier: Autopackage 1.0 (englisch) lwn.net. 30. März 2005. Abgerufen am 24. Januar 2012: „Overall, Autopackage is a very promising project. It makes it possible for third-parties to distribute software for Linux users […] It’s too bad that such a system is still necessary at this time, but it fills a necessary gap until the day that Linux distributions can settle on a standard base system and packaging format.“</ref><ref>Nicholas Vining: Dear Linux Community: We Need To Talk. (englisch) gaslamp Games. 13. Oktober 2010. Abgerufen am 30. Januar 2011.</ref>, sowie auch die Erstellung von Portable Software.<ref name="portableapps">Simon Peter: AppImageKit Documentation 1.0 (englisch, pdf; 38 kB) PortableLinuxApps.org. S. 2-3. 2010. Abgerufen am 29. Juli 2011: „Not easy to move an app from one machine to another: If you’ve used an app on one machine and decide that you would like to use the same app either under a different base operating system (say, you want to use OpenOffice on Fedora after having used it on Ubuntu) or if you would simply take the app from one machine to another (say from the desktop computer to the netbook), you have to download and install the app again (if you did not keep around the installation files and if the two operating systems don’t share the exact same package format - both of which is rather unlikely).“</ref> Durch inkompatible Pakete zwischen den Distributionen ist die Verbreitung von Software ebenfalls erschwert<ref name="lgp2">Eskild Hustvedt: Playing well with distros (englisch) Linux Game Publishing. 24. November 2009. Archiviert vom Original am 21. September 2011. Abgerufen am 15. Januar 2012.</ref>; hiergegen versucht die LSB Standards zu definieren und verbreiten, bis jetzt jedoch nur mit begrenztem Erfolg.<ref name="linuxfordevices">Eric Brown: LSB 4.0 certifications aim to heal Linux fragmentation (en) linuxfordevices.com. 8. Dezember 2010. Abgerufen am 16. November 2011: „The LSB spec outlines interoperability between applications and the Linux operating system, "allowing application developers to target multiple versions of Linux with just one software package," says the LF. Launched in the late '90s, the LSB working group released its first major LSB 1.1 specification in 2001. […]“</ref>

Auch kann es bei der Softwareverwaltung zu Konflikten kommen (die aber erkannt werden): Sind in den Paketen A und B teilweise gleiche Dateien enthalten, können nicht beide Pakete gleichzeitig installiert werden. Auf einem System ohne eine Paketverwaltung würden die Dateien überschrieben, was zu Problemen bei der Ausführung der betroffenen Software führen kann. Ebenso kann es passieren, dass bei einer Aktualisierung des Pakets X auch die Aktualisierung des Pakets Y gefordert wird, Paket Z aber fordert, dass Y die Version beibehält – eine Aktualisierung ist dann nicht möglich. Es zeichnet eine gute Paketverwaltung aus, Konflikte und Abhängigkeiten richtig zu berechnen und zur bestmöglichen Lösung zu kommen, also die richtigen Pakete zu aktualisieren, wenn nötig veraltete Pakete zu löschen und den Konflikt so bestmöglich zu lösen.

Quellenbasierte Distributionen wie etwa Gentoo Linux begegnen diesen Problemen so: Hier werden die Software-Pakete erst auf dem Zielrechner kompiliert. Dabei ist es auch möglich, die Komponenten und damit die Abhängigkeiten eines Paketes anzupassen. Sollte ein bereits installiertes Paket nicht die benötigten Bibliotheken für ein neues Paket installiert haben, wird es kurzerhand neu übersetzt und erneut installiert.

Alternativen und verwandte Konzepte

Nix ist ein neues und alternatives funktionales Paketmanager-System, welches einige der Nachteile traditioneller Paketmanager überwinden soll,<ref>Dolstra, E., de Jonge, M. and Visser, E. "Nix: A Safe and Policy-Free System for Software Deployment." In Damon, L. (Ed.), 18th Large Installation System Administration Conference (LISA '04), pages 79–92, Atlanta, Georgia, USA. USENIX, November 2004.</ref><ref>Dolstra, E. The Purely Functional Software Deployment Model. PhD thesis, Faculty of Science, Utrecht, The Netherlands. January 2006. ISBN 90-393-4130-3.</ref> beispielsweise die distributionsübergreifende "Dependency-Hell".<ref>Pjotr Prins, Jeeva Suresh, and Eelco Dolstra: Nix fixes dependency hell on all Linux distributions (englisch) linux.com. 22. Dezember 2008. Abgerufen am 2. Mai 2015: „The problems: destructive upgrades, software versioning, heterogenous environments. All popular package managers, including APT, RPM and the FreeBSD Ports Collection, suffer from the problem of destructive upgrades. When you perform an upgrade -- whether for a single application or your entire operating system -- the package manager will overwrite the files that are currently on your system with newer versions. As long as packages are always perfectly backward-compatible, this is not a problem, but in the real world, packages are anything but perfectly backward-compatible.“</ref>

Applikationsverbreitung über "Containerisation" oder "App-Verzeichnisse" ist ein alternativer Ansatz, welcher seit ca. Mitte der 2000er für unixode Systeme ausprobiert wird, welcher auf eine konsequente Isolation vom Grundsystem anstelle einer wohldefinierten Integration in das Grundsystem setzt. Eines der ersten Beispiele hier war Autopackage 2005. Weitere sind Zero Install, Portable Linux Apps oder Docker.

Ein der Paketverwaltung nahestehendes Konzept haben aktuelle App Stores, die vor allem für Smartphones zum Einsatz kommen, beispielsweise der Android Market, Mac App Store, Samsung Apps oder der Windows Phone Marketplace. Obwohl sie technisch teilweise auf den gleichen Grundlagen aufbauen wie klassische Paketverwaltungen, existieren hier auch signifikante konzeptuelle Unterschiede, beispielsweise bilden App-Stores eher eine dezentrale "Binärplattformanbieter-zu-ISV"-Architektur anstelle einer zentralisierten Distrostruktur ab.<ref name="molnar2012-1">Ingo Molnar: Technology: What ails the Linux desktop? Part I.. plus.google.com. 17. März 2012. Abgerufen am 16. Juni 2012: „Desktop Linux distributions are trying to "own" 20 thousand application packages consisting of over a billion lines of code and have created parallel, mostly closed ecosystems around them. The typical update latency for an app is weeks for security fixes (sometimes months) and months (sometimes years) for major features. They are centrally planned, hierarchical organizations instead of distributed, democratic free societies.[...]the exact opposite direction: Apple/iOS and Google/Android consist of around a hundred tightly integrated core packages only, managed as a single well-focused project. Those are developed and QA-ed with 10 times the intensity of the 10,000 packages that Linux distributions control. It is a lot easier to QA 10 million lines of code than to QA 1000 million lines of code.“</ref><ref>Ian Murdock: Software installation on Linux: Today, it sucks (part 1) (englisch) ianmurdock.com. 21. Juli 2007. Abgerufen am 1. Mai 2015: „If it’s in your distro of choice, you’re only an apt-get or a yum install away from running it. But if not, you’d better know what you’re doing, have a lot of patience, and understand how to construct effective Google search terms. (And, no, moving everything into the distribution is not a very good option. Remember that one of the key tenets of open source is decentralization, so if the only solution is to centralize everything, there’s something fundamentally wrong with this picture.)“</ref>

Beispiele für Paketverwaltungen

Einzelnachweise

<references />