| |
 |
| Autopackage - Unabhängige Paketinfrastruktur |
|
|
Veröffentlicht durch Ventilator am Sonntag 22. September, 23:39
Aus der Christo Abteilung
|
|
|
|
|
Christian Jaeger schreibt "Dasselbe Programmpaket ohne neucompilieren auf verschiedenen Distros installieren? Mit automatischer Installation von abhängigen Paketen, welche nicht in der Distro vorhanden sind? Ein heute veröffentlichtes Projekt will diese Aufgabe lösen."
|
|
|
|
|
|
|
"Heute wurde die erste Version des Paketformats und Toolsets "Autopackage" publiziert. Es soll besser werden als RPM und .deb, insbesondere soll es dezentral und Distro-unabhängig sein, so dass Softwareautoren selber fertige Pakete ihrer Produkte verteilen können und die Distro-Macher sich wieder ihren Kernaufgaben widmen können anstatt jedes Programm einzupacken das es gibt. Autor Mike Hearn hat einen Eintrag auf Freshmeat gemacht und ist auch im IRC auf freenode.net in #autopackage erreichbar; er kann es kaum erwarten mit anderen Leuten zusammenzuarbeiten."
|
|
|
|
< Nachlese zum 20 Jahre /ch/open-Fest | Druckausgabe | Mehr vom RIAA Defacement > | |
|
|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
|
|
|
|
Von Anonymer Feigling am Monday 23. September, 11:17 MEW (#1)
|
|
|
|
|
Mich verwundert immer wieder, wieviele Leute glauben, sie könnten zuerst mal die "Funktionalität" implementieren, die Sicherheit könnten sie dann später schon noch irgendwie "draufpappen". Ist komplett der falsche Ansatz. Zuerst muss man ein sicheres Fundament für einen Dienst spezifizieren, erst danach kann man sich an die Spezifikation und Implementation der Dienste machen. Gerade wenn man etwas auf der grünen Wiese entwirft, mit dem Ziel, einen neuen Standard zu definieren, sollte man schauen, dass es nicht wieder irgendein Flickwerk mit (bereits voraussehbaren!) Schwächen ist! (Als Beispiel dafür schaue man sich die ungelöste Sicherheitsproblematik bezüglich Interoperabilität von Web Services an. War vorhersehbar.)
Über Sicherheit habe ich bei Autopackage kein Wort gelesen (habe ich es einfach übersehen?). Dabei kann man die beste Funktionalität gleich in den Mülleimer kippen, wenn deren Sicherheit nicht gewährleistet ist. Hier: Ein Mechanismus, der mindestens die Authentizität und Integrität von Software-Paketen in hohem Masse sicherstellt, sollte unbedingt vorhanden sein (wird meistens gelöst mit Package-Signing). Die Integration eines Sandbox-Systems wäre ebenfalls weise.
Eine Initiative wie die Not-So-Bad-Distribution erscheint mir vom Ansatz her wesentlich besser durchdacht.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Welche Sicherheit? Gegen gefakte Pakete? Dies habe ich Mike im Chat auch gesagt, und er hat bestätigt dass er eine public key infrastructure dafür verwenden will. Hier ist es interessant, warum Debian immer noch keine konsequent signierten Pakete hat - da sind praktische Probleme wohl das Problem, und da kann Autopackage sicherlich etwas lernen.
Auch Debian wurde mal von einer oder wenigen Personen gestartet und ist jetzt auch gross, ich sehe drum keine Evidenz dass Mike nicht Erfolg haben könnte. Denn wenn schon die Distro-Macher so etwas nicht entwerfen, dann muss es halt jemand anderes tun.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Nicht unbedingt. Wenn die Dependencies zuerst aus den Distro-eigenen Paketen befriedigt wird, und nur dann Pakete vom Autopackage-Pool geholt werden wenn nicht vorhanden, sollte es kein Problem geben, es kann ja mehrere libc's parallel installiert haben. Das müsste man auch dann machen wenn man ein binäres tar.gz von einem Hersteller installiert, bloss dass man es dann von Hand erledigen muss.
Wichtig ist dass der "Datei-Namespace" für libraries keine Konflikte mit Distro-eigenen Paketen hat. Auf der Autopackage-Website wird das Thema von relocatable Paketen besprochen, das geht in dieselbe Richtung. D.h. ein Autopackage-Paket könnte so verschoben werden dass keine Konflikte auftreten.
Build-depends sind wohl ein anderes Problem - ich denke da an das Puff bei header files von Libc vs. Kernel und wenn sie nicht übereinstimmen. Doch das ist ja nur ein Problem für den *Maintainer* eines Pakets, nicht den Endbenutzer.
Die einzige echte Abhängigkeit von einer Linuxinstallation ist doch die Kernel-Version. In manchen Fällen müssten Pakete für verschiedene Kernel dann wohl separat herausgegeben werden - eins für 2.2, eins für 2.4.
|
|
|
|
|
|
|
