Archiv verlassen und diese Seite im Standarddesign anzeigen : autopackage 1.0
Autopackage 1.0 ist da. Autopackage ist vorallem für Entwickler interessant, da es die möglichkeit bietet, einfach binarys für Linux anzubieten.
autopackage, the multi-distribution binary packaging framework for Linux systems.
* Build packages that will install on many different distros
* Multiple front ends: best is automatically chosen so GUI users get a graphical front end, and command line users get a text based interface
* Multiple language support (both in tools and for your own packages)
* Automatically verifies and resolves dependencies no matter how the software was installed. This means you don't have to use autopackage for all your software, or even any of it, for packages to succesfully install.
Version 1.0 is here. The changes from 0.7 are bugfixes and the integration of the GUI managers which let you uninstall software easily (and in future, hopefully much more). We have also incorporated some great artwork from AJ Ashton, done using our very own Inkscape. Many new translations have been included, and more will appear over time in bugfix releases. Finally, packages that need newer versions of autopackage will correctly upgrade the core code.
Most importantly, this is where we draw the line and promise not to break peoples packages with incompatible changes. From now on, it's a stable and mature piece of software.
changelog (http://cvs.sunsite.dk/viewcvs.cgi/*checkout*/autopackage/main/ChangeLog)
get the source (http://www.wildgardenseed.com/apkg/source.html)
screenies + flash-demo (http://www.wildgardenseed.com/apkg/gallery.html)
coole sache verdammt :)
hab mir grad mal die ganzen faq und die demoseite durchgesehen. ich kann nur hoffen dass das auch unterstützung findet!
das könnte freie OSe wirklich weiterbringen. Ich sehe eine Distri, bei der nur die basis-pakete im apt/rpm/whatever repository stehen, und alle zusätzlichen programme über ein-klick-autoinstall draufgepackt werden können.
die vorteile wären v.a. dass sich die distro-macher voll auf die basis, die sicherheit und die standard (LSB) konformität konzentrieren könnten, während die autopackages für alle distros einheitlich verteilt werden können.
damit hat man zwar zwei paket-systeme auf einem system, aber das relativiert sich insofern, dass autopackage wohl grösstenteils für pakete eingesetzt werden dürfte, von denen keine anderen pakete abhängen - auch wenn das möglich ist. mir gefällt der gedanke, dass spieleinstallationen unter linux deutlich einfacher werden könnten. im moment gibts da ja nur den alten loki-installer, und viele spiele die einfach ein krampf sind was die installation angeht - verglichen mit den sich nun erschliessenden möglichkeiten.
ich wünsche dem projekt viieeel erfolg :)
naja amaroK plant es zu unterstützen, wobei sich zwar einige probleme ergeben, aber ich bin da zuversichtlich..... ansich eine sehr gut sache, und so easy =)
nun, ich denke dass autopackage gerade bei solchen programmen die mehr oder weniger in desktop-suites eingebaut sind, seine stärken nicht so recht ausspielen kann.
viel eher kann es das meiner bescheidenen meinung nach bei standalone produkten wie firefox oder kommerziellen programmen wie nero, spiele und vergleichbare...
ich hoffe stark, dass fedora mandrake und suse darauf setzen werden - wenn das geschieht hätte autopackage eine basis auf der man aufsetzen kann.
nun, ich denke dass autopackage gerade bei solchen programmen die mehr oder weniger in desktop-suites eingebaut sind, seine stärken nicht so recht ausspielen kann.
viel eher kann es das meiner bescheidenen meinung nach bei standalone produkten wie firefox oder kommerziellen programmen wie nero, spiele und vergleichbare...
ich hoffe stark, dass fedora mandrake und suse darauf setzen werden - wenn das geschieht hätte autopackage eine basis auf der man aufsetzen kann.
Fedora, Mandrake und SuSE werden ganz bestimmt nicht auf Autopackage setzen, denn aus den FAQ des Projekts geht ja schon ganz klar hervor, dass Autopackage in keiner Weise dazu geeignet ist, mit Paketen umzugehen, die voneinander abhängig sind, somit ist das Ganze für Distributoren schon mal völlig uninteressant. Es gibt übrigens bereits ein Standard-Paketformat, nämlich RPM:
http://www.linuxbase.org/modules.php?name=FAQ&myfaq=yes&id_cat=11&categories=LSB+Packages
Meiner Meinung nach lautet die naheliegende Frage zu Autopackage: Brauchen wir wirklich noch ein Paketformat, welches sich mit keiner Distribution integriert, anstatt dass man sich auf das meistgenutzte der bereits vorhandenen einigt? Meiner Meinung nach brauchen wir sowas nicht! Schließlich gibt es doch schon RPM.
Der Reihe nach: Wenn ich ein Autopackage installiere, dann wird mir versprochen, es gebe keine Abhängigkeitskonflikte und alles ließe sich sofort installieren. Sorry, kann nicht sein. Wenn Programm A zum Laufen Programm B benötigt und Programm B nicht installiert ist, dann läuft Programm A ganz einfach nicht, unabhängig vom Paketformat. Wenn Programm A daraufhin ein Exemplar von Programm B als Autopackage für mich installiert, dann laufen beide, so weit, so gut.
Wenn ich jetzt aber von meiner Distribution Programm C installieren will, das ebenfalls Programm B benötigt, dann weiß meine Paketverwaltung nicht, dass Programm B schon installiert ist, und klatscht ihr Exemplar über das Autopackage. Irgendwann habe ich keine Lust mehr auf Programm A, aber weil das Autopackage von Programm A ja auch ein Exemplar von Programm B installiert hat, deinstalliere ich beide mit dem Autopackage-Uninstaller -> spätestens jetzt haben wir den Salat.
Was das nette GUI um Autopackage herum angeht: Um ein nettes GUI zu realisieren, braucht man kein neues Paketformat einzuführen. Frontends kann man auch für bestehende Paketformate entwickeln. Das wäre meiner Meinung nach auch der sinnvollere Weg, weil dann wenigstens eine kleine Chance bestünde, dass das Ganze auch akzeptiert wird. So wie es jetzt ist, wird es wahrscheinlich nichts werden, denn es besteht die reale Gefahr, dass Leute sich ihr System durch die Torpedierung ihrer nativen Paketverwaltung mittels Autopackage zerschießen, was zusätzlichen Supportaufwand für die Distributoren bedeutet, deswegen ist es aus Sicht eines Distributors vernünftig, die Finger davon zu lassen.
Übrigens: Ich sehe ehrlich gesagt das Problem nicht, welches Autopackage lösen soll. Für große aufeinander aufbauende Paketgruppen wie KDE oder GNOME besteht keine Alternative zur nativen Paketverwaltung der Distribution. Schon deshalb nicht, weil diese Paketgruppen fast immer recht heftig gepatcht sind, um den Erfordernissen der jeweiligen Distribution gerecht zu werden. Würde man plötzlich einen entweder an Redhat oder vielleicht auch gar nicht angepassten KDE unter SuSE installieren, würde sofort dies und das und jenes nicht mehr gehen, weil YaST im KDE-Kontrollzentrum integriert ist und es auch bleiben soll und so weiter.
Bei allein stehenden Anwendungen ist es schon heute kein allzu großes Problem mehr, RPMs zu machen, die auf allen Distributionen funktionieren. OpenOffice.org gibt es ab der Version 2 als RPMs. StarOffice 8 hat es sogar noch netter gelöst: Das ist ein Archiv, in dem sich die RPMs und ein optionaler grafischer Installer befinden. Der grafische Installer macht nichts anderes, als interaktiv ein paar Fragen zu stellen und dann die RPMs zu installieren, "Experten" können die RPMs auf Wunsch aber auch selbst installieren und den Installer einfach ignorieren. Das ist der richtige Weg.
Übrigens: Auch bei RPMs ist es möglich, den Installationsort zu bestimmen. Das wird von RPM-Kritikern immer wieder gerne unterschlagen, aber es stimmt nicht, dass man das nicht kann. Dafür empfehle ich die Lektüre der Manpage von RPM, inbesondere den Abschnitt "install-options -> --prefix / --relocate". Das Acrobat Reader-RPM von Adobe kann ich mir beispielsweise installieren, wohin ich will, ich kann es sogar nach der Installation mit einem simplen Befehl jederzeit beliebig verschieben und habe trotzdem noch die Vorteile der RPM-Datenbank.
Fazit: Meiner Meinung nach sollte man den Fokus statt auf ein neues Paketformat, das sich sowieso nicht durchsetzen wird, lieber auf benutzerfreundliche Frontends setzen. Zusätzlich einigt man sich auf ein bereits bestehendes Paketformat, wobei das ja schon längst geschehen ist. Und eines muss man noch machen: Man muss sich auf gemeinsame Paketnamen einigen, damit RPMs von Drittherstellern diese gemeinsamen Paketnamen als Abhängigkeiten eintragen können. Denn oft scheitert es nur daran, dass gleiche Pakete unterschiedliche Namen haben, aber dafür gibt es ja schließlich den "provides"-Tag bei RPMs.
Schwachsinnige Imitation der häßlichen Windows-Installations-Programme. Fehlt nurnoch, dass es davo jetz auch noch wie bei Windows (Installshield und co) ein Dutzend verschiedene gibt (ist ja schon zumindest das zweite, da war schonmal was ähnliches in der Presse neulich), damit sich dann jedes Programm ein wenig anders installieren lässt...
Achja und was das eigentlich Ziel, nämlich einer Ergänzung vom RPM/etc-Core angeht: Wo ist der vorteil zwischen den Binarys in nem tarball?
Fedora, Mandrake und SuSE werden ganz bestimmt nicht auf Autopackage setzen, denn aus den FAQ des Projekts geht ja schon ganz klar hervor, dass Autopackage in keiner Weise dazu geeignet ist, mit Paketen umzugehen, die voneinander abhängig sind, somit ist das Ganze für Distributoren schon mal völlig uninteressant.
Autopackage kann auch mit Abhängigkeiten umgehen. Allerdings ist es für komplexe Abhängigkeiten weniger geeignet. Zur Installation zusätzlicher Programme reicht es aber, wer aber z. B. X.org installieren möchte, für den ist Autopackage nichts. Autopackage möchte ja auch nicht die traditionellen Paketformate ersetzen, sondern eine distributionsübergreifende Möglichkeit zur Installation in der Distribution nicht enthaltener Programme schaffen.
Es gibt übrigens bereits ein Standard-Paketformat, nämlich RPM:
http://www.linuxbase.org/modules.php?name=FAQ&myfaq=yes&id_cat=11&categories=LSB+Packages
RPM ist aber nicht so einheitlich. Ich gibt immer wieder mal Probleme, ein Fedora-RPM unter SuSE oder umgekehrt zu installieren. Und automatisch Abhängigkeiten auflösen - insbesondere mit Drittpaketen, also Paketen, die nicht zur Distribution gehören - kann es auch nicht. Als Format für eine Distribution ist aber RPM problemlos geeignet, aber für Drittsoftware problematisch.
Meiner Meinung nach lautet die naheliegende Frage zu Autopackage: Brauchen wir wirklich noch ein Paketformat, welches sich mit keiner Distribution integriert, anstatt dass man sich auf das meistgenutzte der bereits vorhandenen einigt? Meiner Meinung nach brauchen wir sowas nicht! Schließlich gibt es doch schon RPM.
Doch, wir brauchen ein Format, das distributionsübergreifend funktioniert und die Probleme dabei angeht. Autopackage ist auch mehr ein Format, es gibt den Programmieren auch Hilfestellung, distributionsübergreifende Binärpakete zu erstellen.
Der Reihe nach: Wenn ich ein Autopackage installiere, dann wird mir versprochen, es gebe keine Abhängigkeitskonflikte und alles ließe sich sofort installieren. Sorry, kann nicht sein. Wenn Programm A zum Laufen Programm B benötigt und Programm B nicht installiert ist, dann läuft Programm A ganz einfach nicht, unabhängig vom Paketformat. Wenn Programm A daraufhin ein Exemplar von Programm B als Autopackage für mich installiert, dann laufen beide, so weit, so gut.
Wenn ich jetzt aber von meiner Distribution Programm C installieren will, das ebenfalls Programm B benötigt, dann weiß meine Paketverwaltung nicht, dass Programm B schon installiert ist, und klatscht ihr Exemplar über das Autopackage. Irgendwann habe ich keine Lust mehr auf Programm A, aber weil das Autopackage von Programm A ja auch ein Exemplar von Programm B installiert hat, deinstalliere ich beide mit dem Autopackage-Uninstaller -> spätestens jetzt haben wir den Salat.
Ja, das ist noch ein Problem. Die Zusammenarbeit mit den Paketformaten der einzelnen Distributionen soll aber in Zukunft verbessert werden, damit sich Autopackage besser integriert.
Was das nette GUI um Autopackage herum angeht: Um ein nettes GUI zu realisieren, braucht man kein neues Paketformat einzuführen. Frontends kann man auch für bestehende Paketformate entwickeln. Das wäre meiner Meinung nach auch der sinnvollere Weg, weil dann wenigstens eine kleine Chance bestünde, dass das Ganze auch akzeptiert wird. So wie es jetzt ist, wird es wahrscheinlich nichts werden, denn es besteht die reale Gefahr, dass Leute sich ihr System durch die Torpedierung ihrer nativen Paketverwaltung mittels Autopackage zerschießen, was zusätzlichen Supportaufwand für die Distributoren bedeutet, deswegen ist es aus Sicht eines Distributors vernünftig, die Finger davon zu lassen.
Das kannst du schon jetzt durch manuelle Installation weiterer Programme, Austausch einzelner Pakete etc. Außerdem dient Autopackage nicht der Installation von Basissoftware.
Übrigens: Ich sehe ehrlich gesagt das Problem nicht, welches Autopackage lösen
soll. Für große aufeinander aufbauende Paketgruppen wie KDE oder GNOME besteht keine Alternative zur nativen Paketverwaltung der Distribution. Schon deshalb nicht, weil diese Paketgruppen fast immer recht heftig gepatcht sind, um den Erfordernissen der jeweiligen Distribution gerecht zu werden. Würde man plötzlich einen entweder an Redhat oder vielleicht auch gar nicht angepassten KDE unter SuSE installieren, würde sofort dies und das und jenes nicht mehr gehen, weil YaST im KDE-Kontrollzentrum integriert ist und es auch bleiben soll und so weiter.
Guck mal auf deren Homepage. Autopackage dient nicht zur Installation ganzer Desktops, sondern nur zur Installation zusätzlicher Programme.
Bei allein stehenden Anwendungen ist es schon heute kein allzu großes Problem mehr, RPMs zu machen, die auf allen Distributionen funktionieren. OpenOffice.org gibt es ab der Version 2 als RPMs. StarOffice 8 hat es sogar noch netter gelöst: Das ist ein Archiv, in dem sich die RPMs und ein optionaler grafischer Installer befinden. Der grafische Installer macht nichts anderes, als interaktiv ein paar Fragen zu stellen und dann die RPMs zu installieren, "Experten" können die RPMs auf Wunsch aber auch selbst installieren und den Installer einfach ignorieren. Das ist der richtige Weg.
Dabei werden Abhängigkeiten aber nicht berücksichtigt und der Benutzer darf diese selbst auflösen.
Übrigens: Auch bei RPMs ist es möglich, den Installationsort zu bestimmen. Das wird von RPM-Kritikern immer wieder gerne unterschlagen, aber es stimmt nicht, dass man das nicht kann. Dafür empfehle ich die Lektüre der Manpage von RPM, inbesondere den Abschnitt "install-options -> --prefix / --relocate". Das Acrobat Reader-RPM von Adobe kann ich mir beispielsweise installieren, wohin ich will, ich kann es sogar nach der Installation mit einem simplen Befehl jederzeit beliebig verschieben und habe trotzdem noch die Vorteile der RPM-Datenbank.
Aber ein einfacher Benutzer kann damit nicht Pakete in sein Homeverzeichnis installieren, was z. B. mit Quellpaketen oder Systemen wie Konstruct problemlos geht.
Fazit: Meiner Meinung nach sollte man den Fokus statt auf ein neues Paketformat, das sich sowieso nicht durchsetzen wird, lieber auf benutzerfreundliche Frontends setzen. Zusätzlich einigt man sich auf ein bereits bestehendes Paketformat, wobei das ja schon längst geschehen ist. Und eines muss man noch machen: Man muss sich auf gemeinsame Paketnamen einigen, damit RPMs von Drittherstellern diese gemeinsamen Paketnamen als Abhängigkeiten eintragen können. Denn oft scheitert es nur daran, dass gleiche Pakete unterschiedliche Namen haben, aber dafür gibt es ja schließlich den "provides"-Tag bei RPMs.
<Ironie>Am einfachsten wäre natürlich ein Einheitslinux, dann hätten wir die Probleme nicht.</Ironie> Aber Autopackage versucht die Probleme der Vielfalt zu lindern.
Autopackage kann auch mit Abhängigkeiten umgehen. Allerdings ist es für komplexe Abhängigkeiten weniger geeignet. Zur Installation zusätzlicher Programme reicht es aber, wer aber z. B. X.org installieren möchte, für den ist Autopackage nichts.
Tut es das wirklich? Angenommen, ich hätte k3b mit autopackage installiert und wollte jetzt mein System aufräumen. Verhindert autopacke, dass ich cdrecord deinstalliere, wenn cdrecord nur von dem mit autopackage installierten k3b benötigt wird? Ich weiß das ehrlich gesagt nicht, aber wenn es das nicht tut, dann verdient es das Prädikat "kann mit Abhängigkeiten umgehen" meiner Meinung nach nicht.
RPM ist aber nicht so einheitlich. Ich gibt immer wieder mal Probleme, ein Fedora-RPM unter SuSE oder umgekehrt zu installieren. Und automatisch Abhängigkeiten auflösen - insbesondere mit Drittpaketen, also Paketen, die nicht zur Distribution gehören - kann es auch nicht.
Natürlich geht das! Ist doch unter dem zuvor von mir geposteten Link schon ganz genau beschrieben: "Package repository management tools like APT or YUM sit at a layer above the packages themselves." Ein höher liegendes Problem (Auflösen der Abhängigkeiten) löst man nicht, indem man an der Basis herumfuhrwerkt, sondern indem man das höherliegende Problem gezielt und minimal-invasiv angeht und Frontends a la yum/apt/urpmi/yast verwendet und verbessert.
Doch, wir brauchen ein Format, das distributionsübergreifend funktioniert und die Probleme dabei angeht. Autopackage ist auch mehr ein Format, es gibt den Programmieren auch Hilfestellung, distributionsübergreifende Binärpakete zu erstellen.
"Distributionsübergreifend" klingt viel besser, als es eigentlich ist. Das Problem "Die Hälfte meiner Gäste isst lieber Fisch als Fleisch, die andere Hälfte ist lieber Fleisch als Fisch" löst man nicht, indem man ein Gericht serviert, das keinem schmeckt, sondern mit einem Gericht, das allen einigermaßen schmeckt. Die in die von Dir genannte Hilfestellung investierte Energie kann man genausogut "umleiten", indem man Hilfestellungen anbietet, distributionsübergreifende RPMs zu erstellen.
Ernsthaft, ich habe den Eindruck, autopackage solle es den Anbietern von Paketen um jeden Preis möglichst einfach machen, ohne ausreichend an die Benutzer zu denken. Als Benutzer darf ich mich dank autopackage um zwei Paketverwaltungen parallel kümmern, ich muss mir merken oder auf einen Zettel schreiben, welche Basispakete meiner Distribution ich keinesfalls deinstallieren darf, damit die autopackage-Programme noch funktionieren usw. Nein, das ist nichts, das ist halbgar.
Jeder Versuch einer Lösung muss benutzerfreundlich und konsistent sein. Wenn er das nicht ist, dann lässt man es lieber bleiben und behält die bisherige Vorgehensweise bei. Aber ich sehe es schon kommen, mit folgenden Anfragen wird dieses Forum überhäuft werden, wenn autopackage sich verbreitet:
- Hilfe, mein Firefox geht nicht mehr, seit ich gtk2 deinstalliert habe, um Platz zu sparen, und keiner hat mich davor gewarnt!
- Hilfe, mein k3b geht nicht mehr, seit ich allerhand Zeugs deinstalliert habe, aber ich weiß nicht mehr, was ich deinstalliert habe, sagt mir doch bitte ganz schnell, was ich wieder installieren muss!
- Hilfe, Linux ist so doof und so benutzerunfreundlich! Unter Windows sehe ich alle meine Software in der Systemsteuerung beisammen, unter Linux sehe ich die Hälfte nur in YaST und die andere Hälfte nur im autopackage. Das ist voll doof, ich werde formatieren und Windows installieren!
- Hilfe, mein Kumpel hat mir erzählt, dass ich Software mit "rpm -e <Paketname>" deinstallieren muss, aber bei OpenOffice.org, welches ich mit autopackage installiert habe, geht es nicht, was muss ich machen?
- Hilfe, Hilfe, Hilfe...
Irgendwie habe ich die Befürchtung, dass dieser "wir versuchen es allen recht zu machen"-Ansatz mehr Probleme erzeugen wird, als er löst. Stattdessen wäre es doch wesentlich sinnvoller, es gleich "richtig" zu machen, was auch immer das heißt. Bei der Gelegenheit könnte man auch gleich mit ein paar sehr weit verbreiteten Märchen aufräumen, zum Beispiel mit dem Märchen, dass man mit RPMs keine Abhängigkeiten auflösen kann.
<Ironie>Am einfachsten wäre natürlich ein Einheitslinux, dann hätten wir die Probleme nicht.</Ironie> Aber Autopackage versucht die Probleme der Vielfalt zu lindern.
Quatsch, kein Mensch will ein Einheitslinux und kein Mensch braucht es überhaupt. Das sieht man doch daran, dass es schon mit den jetzt etablierten Mitteln einigermaßen machbar ist. Raum für Verbesserungen gibt es natürlich immer, insbesondere bei Namenskonventionen.
Man müsste mal aufzählen, über was man sich schon so aufgeregt hat ...
Es ist doch schön, wenn es noch mehr Vielfalt gibt. Das wollen doch immer alle!? Wieso nicht bei Packetformaten?
Ich persönlich würde es ziemlich cool finden, wenn ich z.B. AcrobatReader 7 einfach so installieren und auch deinstallieren könnte. Genau das bietet mir Autopackage (z.Zt. zwar mit LinCity - was nicht rockt imho)!
Gibt es z.Zt. eine bessere Methode?
Dieses oft angesprochene ./configure && make && make install ist nichts für Leute, die sich nicht mit den Details auskennen. Ich habe es probiert und hinbekommen, aber es hat rgendwie so gar keinen Spaß gemacht!
Tut es das wirklich? Angenommen, ich hätte k3b mit autopackage installiert und wollte jetzt mein System aufräumen. Verhindert autopacke, dass ich cdrecord deinstalliere, wenn cdrecord nur von dem mit autopackage installierten k3b benötigt wird? Ich weiß das ehrlich gesagt nicht, aber wenn es das nicht tut, dann verdient es das Prädikat "kann mit Abhängigkeiten umgehen" meiner Meinung nach nicht.
Noch nicht. Allerdings soll es implementiert werden.
Natürlich geht das! Ist doch unter dem zuvor von mir geposteten Link schon ganz genau beschrieben: "Package repository management tools like APT or YUM sit at a layer above the packages themselves." Ein höher liegendes Problem (Auflösen der Abhängigkeiten) löst man nicht, indem man an der Basis herumfuhrwerkt, sondern indem man das höherliegende Problem gezielt und minimal-invasiv angeht und Frontends a la yum/apt/urpmi/yast verwendet und verbessert.
Dann muss man aber für jedes Zusatzpaket so ein Repository aufbauen, dass außerdem noch distributionsübergreifend funktionieren muss.
Wir werden ja sehen, ob sich Autopackage durchsetzt oder nicht. Die Benutzer und Entwickler werden entscheiden ...
Man müsste mal aufzählen, über was man sich schon so aufgeregt hat ...
Es ist doch schön, wenn es noch mehr Vielfalt gibt. Das wollen doch immer alle!? Wieso nicht bei Packetformaten?
Wie bitte? Vielfalt bei Paketverwaltungen? Paketverwaltungen sind das beste Beispiel für eine Sache, bei der Vielfalt gerade eben _nicht_ begrüßenswert ist. Und schon gar nicht auf einem einzigen System. Wenn es zumindest ein in sich schlüssiges System wäre, könnte man ja noch darüber diskutieren, aber eine zweite, nicht integrierte Paketverwaltung auf einem System, das schon eine native Paketverwaltung hat, braucht kein Mensch.
Ich persönlich würde es ziemlich cool finden, wenn ich z.B. AcrobatReader 7 einfach so installieren und auch deinstallieren könnte.
Kannst Du doch schon längst:
ftp://ftp.adobe.com/pub/adobe/reader/unix/7x/7.0/enu/AdobeReader_enu-7.0.0-1.i386.rpm
OK, es ist eine halbe Provokation, aber im Ernst, laut Selbsteinschätzung des Debian-Projekts ist alien das Tool, das Debian zu einer LSB-konformen Distribution macht, also kann man doch alien verwenden, um das RPM zu konvertieren. Es funktioniert!
Aber um mal wieder konstruktiv zu werden:
Gibt es z.Zt. eine bessere Methode?
Ja, gibt es! Gerade entdeckt:
ftp://ftp.stardiv.de/pub/OpenOffice.org/developer/install_scripts
OpenOffice.org wird es in Zukunft nur noch als RPMs offiziell geben, weil das eben laut LSB das Paketformat der Wahl ist. Diese Skripte, die unter dem oben genannten Link zu finden sind, ermöglichen es, die OpenOffice.org-RPMs
- auf Systemen zu installieren, die gar kein rpm haben
- ohne root-Zugang im Homeverzeichnis zu installieren
Wie geht es? Ganz einfach: Wenn rpm vorhanden ist, wird es verwendet und alle installierten Dateien landen in der RPM-Datenbank. Wenn rpm nicht vorhanden ist, werden die Dateien einfach aus den RPMs extrahiert, die Abhängigkeiten manuell überprüft und anschließend die Dateien in autopackage-Manier unkontrolliert in das System gerotzt. Ein Deinstallationsskript gibt es auch dazu. Und weil das Ganze völlig unabhängig von rpm funktioniert, braucht man auch keinen root-Zugang und kann wie gewohnt ins Homeverzeichnis installieren.
_Das_ ist ein vernünftiger Ansatz. Man verwendet das laut LSB auserkorene Tool, um das Programm zu installieren und nur wenn es nicht verfügbar ist, arbeitet man an der nativen Paketverwaltung vorbei. Das ist im Gegensatz zum gleichmacherischen Pauschalansatz von autopackage minimalinvasiv und funktioniert einfach, mit dem Unterschied, dass nicht, wie bei autopackage, alle, sondern nur die nicht LSB-konformen nativen Paketverwaltungen torpediert werden. Anstelle von autopackage sollte man lieber diesen OpenOffice.org-Ansatz generalisieren und für allgemeine Zwecke verfügbar machen.
oracle2025
06.04.05, 06:58
Das Paketformat ist nur ein Tool von den Autopackage Machern, sie haben auch noch andere Entwickelt, die sehr nützlich sind, wenn man binär Pakete erstellen will die auf mehreren Distributionen funktionieren sollen.
z.B. das binreloc tool, und spezielle scripte, die den gcc mit bestimmten Parametern aufrufen um Distributionsspezifische Konflikte zu umgehen.
Ob man dann das Autopackage-Paket-Format verwendet, bleibt jedem Entwickler selbst überlassen, aber der Wert der obengenannten Tools ist IMHO nicht zu unterschätzen!
dem kann ich nur zustimmen ...
den kritikern von weiter oben kann man nur nahelegen die autopackage-FAQ zu lesen.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.