zico
Hi Leute
Ich entwickel mich langsam zu einem richtigen Viel-Poster, da ich immer gern frage bevor ich selbst etwas "neues" probiere um vielleicht einen besseren Weg kennenzulernen.
Folgendes:
Angenommen ich kriege irgendwoher ein Programm, welches lediglich im - beispielsweise - RPM-Format vorhanden ist. Auch angenommen dieses Programm sei kommerziell/closed source o.ä.
Klar mögen nun einige, im übertragenden Sinne sagen: "Solche Programme sollte man nicht nutzen".
Nun gibt es ja Möglichkeiten, RPMs, DEBs, TGZs etc zu entpacken. Aber wie würdet ihr diese in das System integrieren?
Um ehrlich zu sein, habe ich bisher noch kein "Konvertierungsprogramm" von RPM/DEB/etc -> ARCH-Paket gefunden.
Sicher kann ich die entpacketen Dateien auch ins Dateisystem kopieren, was aber bei mehreren Paketen sehr unübersichtlich würde. Um dem vorzubeugen könnte man natürlich ein Deinstallationsscript schreibseln (ein paar rm Anweisungen).
Eine andere Möglichkeit, die mir noch einfiele wäre, die Dateien halt nach /home/$user/prog_xyz/ kopieren (falls man es nur für einen Nutzer braucht) und halt das System so anpassen, dass ggf. vorhandenen Libs, welche das Programm mitliefert, auch gefunden werden. PATH kann natürlich auch genutzt werden.
Beides erscheint mir nicht gerade ziemlich produktiv.
Falls ich natürlich jetzt in AUR oder in den Repos ein super Konvertierungsprogramm übersehen habe - obwohl ich gelesen habe, dass solche nicht offiziell unterstützt werden sollen - , bitte ich um Entschuldigung und dann kann der Thread ja auch gelöscht werden.
Pierre
Schaue am besten erstmal im AUR nach, ob nicht ein entsprechendes PKGBUILD vorhanden ist. Falls nicht, kannst Du Dir ein neues POKGBUILD bauen, daß das RPM mit rpmextract entpackt und die Dateien an die richtigen Stellen kopiert.
Wichtig ist nur, daß man nichts an der Paketverwaltung vorbei installiert.
zico
Hm das is natürlich auch eine Lösung. Aber um auf den letzten Satz zu sprechen zu kommen:
"Wichtig ist nur, daß man nichts an der Paketverwaltung vorbei installiert."
Warum ist es bei Arch eigentlich generell ... wie soll ich sagen... *nicht gern gesehen*, etwas *nicht* nach dem Arch-Way zu machen - sprich direkt compilieren und installieren? Okay sicher ist dann die Verwaltung des Pakets einfacher (man braucht die Source nicht) und im Falle, dass man eine Lib installiert, von der ander eProgramme abhängen kommt pacman auch nicht durcheinander. Das is mir alles klar.
Aber was spricht generell dagegen? Ich compilier gern mal so ein Programm, lass die Quellen in /usr/src und lass ABS eigentlich dann aussen vor (so lange halt Abhängigkeitsprobleme ausgeschlossen werden können)... Vllt täusche ich mich, aber mir fällt auf, dass eben viele Arch Nutzer zumindest immer "auf den Arch-Way pochen". Das interessiert mich. Sicher is das die sauberste Lösung. Aber bringt die "nicht-Arch-Way" Lösung (also von Hand compilieren und installieren) bei Arch Probleme wo es bei anderen Distris nicht tut oder hat es was generell damit zutun, dass es eben *sauber* ist und mit ABS auch noch einfach zudem?
Beispielsweise finde ich es beim NVidia Treiber, den ich zwecks eigenem Kernel eh nicht aus den Repos nehmen kann sinnlos immer ein Paket zu bauen, wenn der Installer auch so wunderbar funzt. Nur so als Beispiel.
wakeup
also ich behaupte das das ABS darauf basiert das user PKGBUILD's zu noch nicht vorhanden paketen schreiben und diese dann auch mit den anderen usern teilen. wenn man das programm einfach kompiliert hat nur einer was davnon.
zico
Okay, das ist auch ein Argument, würde aber auch gelten, wenn ich eben ein Paket aus meinen Sourcen baue - egal auf welcher Distribution.
Ich frage mich halt wo der Nachteil beim Nicht-Paket Weg liegt bei Arch und bei anderen Distris. Ich finds ja klasseimmer Pakete zu haben, frage mich aber, warum ich dieses "Bau am besten immer Pakete" bisher nur bei Arch lese/höre.
Pierre
Das gilt natürlich genauso für alle anderen Distributionen, die ein Paketverwaltungssystem haben. Je nachdem was Du per Hand installierst, wirst Du später Probleme beim Auflösen von Abhängigkeiten, Datei-Konflikten etc. bekommen. Und weißt Du dann wirklich noch, welche Datei zu welcher Software gehört? Wie deinstallierst oder aktualisierst Du solche Software?
Schrauber
Naja, ich hab mich sehr schnell mit ABS angefreundet. Inzwischen bau ich immer PKGBUILDs.
Es ist einfach so:
Keiner verbietet Dir, irgendwas aus den Sourcen zu installieren. Es ist Dein System und da kannst Du machen was immer Du willst.
ABER:
Wenn Du ein Paket baust, dann hast Du die Sicherheit, das Du es auch wieder sauber und Rückstandsfrei aus dem System heraus operieren kannst. Wenn Du direkt aus Sourcen installierst, dann werden die Libs und Binarys quasi flächendeckend auf dem System verteilt. Das kriegst Du nie wieder sauber raus.
Probier es mit PKGBUILD. Es ist nach kurzer Einarbeitung wirklich absolut simpel. Kein Vergleich zu RPM oder DEB.
zico
Hm ja also hör ich das deswegen so oft, weil hier die Nutzer sehr sorgsam sind. 🙂
Nun - ich finde bei einigen Programmen geht das händische compilieren janoch. Ein Spiel wie xmoto is höchstwahrscheinlich keine Abhängigkeit eines anderen Paketes. Auch wenn ich dann noch die Quellen behalte (/usr/src) kann ich das Paket auch wieder einfach deinstallieren.
Das ist natürlich nun jetzt nur Theorie - auf welcher ja meine Fragerei basiert hat. Im Grunde begrüße ich es natürlich, die Ordnung unter Paketen auf eine möglichst hohe Stufe zu stellen.
[gelöscht]
Naja, andere Faktoren spielen da wohl eine wesentlichere Rolle.
Das Hauptprolem dürfte sein, dass pacman von den manuell installieren Programmen / libraries nichts weiß und deshalb dann diese auch beim Installieren / deinstallieren von Software und insbesondere bei der Abhängigkeitsprüfung nicht beachtet.
Gerade wenn du eine Library als Abhängigkeit installieren musst, die du schon manuell installiert hast, findet pacman einen Konflikt und bricht den Vorgang einfach ab - und das schlimmste, was du tun kannst, ist Pacman dann zu zwingen, es dennoch zu installieren.
Dabei kannst du dein System dabei so sehr durcheinanderwürfeln, dass es nicht mehr funktioniert.
Ob ich nun aber ./configure && make && make install in eine Shell eintippe oder das in ein PKGBUILD klatsche, ist eigentlich kein großer Unterschied im Aufwand und wenn du zusätzlich bedenkst, dass du irgendwann auf neue Versionen updaten möchtest, wird das PKGBUILD auf Dauer sogar der geringere Aufwand sein.
Eigentlich muss die Frage nicht lauten, wieso manuelles Installieren bei Arch so ungern gesehen wird, sondern wieso es bei anderen Distris teilweise Gang und Gäbe ist.
Wieso sollte man Verkehrspolizisten den Verkehr an einer Kreuzung manuell regeln lassen, wenn da doch eine funktionierende Ampel steht?
danlei
Wenn Du Deine ohne ABS aus den Quellen gebauten Programme in einen ausschließlich dazu genutzten Verzeichnisbaum installierst (per DESTDIR, prefix und Co.), hat das Ganze auf Dein System an sich überhaupt keine negativen Auswirkungen. Kandidaten wären z.B. /usr/local, welches ja bei Arch eh leer sein sollte, oder einfach Dein Heimverzeichnis. Die einzigen Probleme, die Dich erwarten, betreffen eben das 'zu Fuß' gebaute Programm und wurden bereits genannt.
Aber ich meine, dass die Frage falsch gestellt ist:
Warum sollte man ein Programm am Paketmanagement vorbei bauen wollen?
Gibt es einen guten Grund dafür? Ein PKGBUILD zu schreiben ist ein minimal höherer Aufwand, welcher einen ganzen Batzen Vorteile bringt. Anders ausgedrückt ist der größte Nachteil, auf die Vorteile der (guten und einfachen) Paketverwaltung zu verzichten.
zico
"Eigentlich muss die Frage nicht lauten, wieso manuelles Installieren bei Arch so ungern gesehen wird, sondern wieso es bei anderen Distris teilweise Gang und Gäbe ist."
Und genau das hat mich verwundert.
Vieles spricht eben dafür ein Paket zu bauen und doch kriegt man überall das "compilier es doch von Hand" an denKopf geknallt.
Die Vorteile eines Paketes liegen natürlich auf der Hand. Viele Quellen bieten ein "make uninstall" garnicht mehr an, as das saubere Entfernen eine Programmes ziemlich schwer macht.
Solche hab ich früher (auf SuSE) mit /home/user/proggi/ als Prefix gebaut...
Wie auch immer... Ich kann den Beiträgen hier ja nur beipflichten - im Grunde hab ich mich also nicht über Arch gewundert ^^
dongiovanni
Meiner Meinung kriegst du das ./configure && make && make install so häufig an den Kopf geknallt, weil es unter vielen Distributionen einfach schwieriger ist, Pakete zu erstellen. (rpm und deb sind viel aufwendiger zu erstellen)
danlei
Das stimmt auf jeden Fall. Bei anderen Distributionen hab ich es, ehrlich gesagt, nie in Erwägung gezogen, ein Paket zu erstellen.
zico
Zuf Verteidigung muss ich sagen, dass es mit checkinstall wirklich sehr einfach ist, ein Paket zu erstellen. ./configure && make && checkinstall". Der Rest geht quasi automatisch. Okay gehört hier nicht hin.
Zumindest bin ich nun wieder etwas schlauer geworden. Deswegen nutze ich ja Arch: neues lernen.