ibu
Anmeldungsdatum: 21. März 2006
Beiträge: 551
Wohnort: Berlin
|
Fredo schrieb in http://forum.ubuntuusers.de/topic/28496/quote/192964/ Fredo hat geschrieben:
Andere Software, die man z.B. gar nicht zu installieren braucht sondern einfach auspacken kann, wandert bei mir nach /opt. Dann kommt ein symlink oder ein kleines Starterskript nach /usr/local/bin. Seit dem ich rausgefunden habe, wie man ein eigenes Verzeichnis dem PATH hinzufügen kann, habe ich viele kleinere Skripte aber auch in ~/bin, das lässt sich einfacher händeln, finde ich.
Ich fange mal mit einer Skizze für einen Wikiartikel an. ☺ Das Thema "Installation einer Anwendung, die nicht im Paket zur Verfügung steht" ist sicher für viele Neulinge interessant - gerade auch in den Details. Da ich für grundlegende Systempflege die Konsole als Arbeitsmittel als nützlich ansehe, könnte das Ganze gleichzeitig ein Übungsbeispiel für die Arbeit mit der Konsole werden. Ich würde mich freuen, wenn die Konsolenkenner die Skizze ergänzen würden. Habe ich etwas vergessen? Wenn Schritte fehlen, oder sonst etwas an der Skizze verbesserungswürdig ist, bitte ich um Ergänzung und Korrektur. ******* Skizze für Wikiartikel ********* Edit am 13.4.06: Die aktuelle Fassung der Skizze findet ihr auf: http://borumat.de/kubuntu-ubuntu-tipps#firefox-installieren'''
Du möchtest die aktuellste deutschsprachige Version von Firefox 1.5 nutzen?
Das "$" steht für das Nutzer-Prompt in der Konsole Das Nutzerverzeichnis lautet in diesem Beispiel: /home/leyla
1 Aktualisierung der Paketlisten $ apt-get update
2 Prüfen, ob der String Firefox in der Liste vorkommt $
3 Prüfen, welche Version von Firefox als Paket zur Verfügung steht $
4 Prüfen, welche Sprache dieses Paket enthält $
5 Deaktivierung des Paketes in der Paketliste und der sources.list Falls ein Paket zu einer weniger aktuellen FF-Version existiert, wird es in der Paketliste deaktiviert: damit bei künftigen Updates nicht versehentlich diese ältere FF-Version geladen wird. Denn eine entpackte Version kann nicht vom Paketmanager upgegradet werden.
6 Prüfen, ob in sources.list ein separater Eintrag für Firefox-Pakete existiert $ Falls er existiert wird er vorsorglich deaktiviert. Editiere dazu die sources.list mit einem Editor mit Rootrechten: $
7 Ermittlung einer Quelle für Version 1.5de von Firefox bei Google Ergebnis: http://www.firefox-browser.de/linux.php http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.5.0.1/linux-i686/de/firefox-1.5.0.1.tar.gz
8 Download des Archives $ wget http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.5.0.1/linux-i686/de/firefox-1.5.0.1.tar.gz Dieser Befehl lädt das Archiv in ein temporäres Verzeichnis.
9 Entpacken des Archives in das /opt $ Der Browser soll allen Nutzern zur Verfügung stehen. Das Nutzerverzeichnis soll möglichst schlank bleiben und keine Programmversionen enthalten, die auch anderen Nutzern zur Verfügung stehen sollen.
10 Sinnvolle Pfadangabe für das Profil $ Das Profil soll sich in dem Nutzerverzeichnis befinden, wo sich auch andere Nutzereinstellungen befinden, die von Anwendungens stammen, die normal aus Paketen installiert wurden.
11 Angabe des Profilpfades in Firefox Falls nötig, wird der Profilpfad manuell im Profilmanager angegeben, damit sichergestellt ist, dass Erweiterungen richtig installiert werden können und es keine Probleme bei automatischen Updates aus Firefox heraus geben kann: von Erweiterungen oder von Firefox selbst
12 Anpassung von Berechtigungen Falls nötig, werden diese angepasst $
13 Ergänzung der Variable PATH Dies ermöglich später das Starten von Firefox aus der Konsole heraus, allein durch das Eingeben des Wortes "firefox" $
14 Ergänzung eines Links im KMenü des KDE-Desktops Dieser ermöglicht einen leichten Zugriff auf Firefox "KMenü > Rechtsklick: Eintrag hinzufügen > Feld Name: Firefox > Feld Befehl: Firefox"
|
Dee
Anmeldungsdatum: 9. Februar 2006
Beiträge: 20087
Wohnort: Schwabenländle
|
Die Idee ist nicht schlecht, aber als Übung für Konsole würde ich es nicht ansehen. Es sollte jedem User freigestellt sein, was er nutzen möchte, daher sollte man niemanden die Konsole aufzwingen. Zumal, wenn ich fertig bin, alle Dinge auch z.B. Nautilus ausgeführt werden können. Zum Text: Ich finde den Artikel sehr firefoxlastig, vor allem die Schritte 1-8 sind unnötig, wenn der Artikel wirklich kein Firefox-Artikel sein soll, sondern für das Thema "Installation einer Anwendung, die nicht im Paket zur Verfügung steht" gedacht ist. Denn nicht jedes Paket gibt es überhaupt in den Quellen oder ist vorinstalliert. Vor allem muß man den alten Firefox gar nicht installieren, da sich das Profil eh woanders befindet. Die Punkte sollte man in meinen Augen streichen... 10-12. Habe ich nicht verstanden. Warum willst Du einen Pfad fürs Profil angeben? Oder anders: Was ist am Standardprofil /home/user/.mozilla/firefox in Deinem Fall schlecht? Und wieder kann ich nur sagen, daß das FF-spezifisch ist. Bei der wenigstens Software kann man den Profilpfad angeben. 13. Hier würde ich nicht die Pfadvariable ersetzen, sondern lieber nen Softlink von /usr/bin/programmname nach /install/verzeichnis/programmname. Also der Artikel beschränkt sich bei mir auf die Punkte: 1. Paket entpacken 2. Softlink setzen 3. Verknüpfung erstellen Gruß, Dee
|
Unki
Anmeldungsdatum: 23. März 2005
Beiträge: 5761
Wohnort: Essen
|
So wie ich das im ersten Überblick sehe, sind Teile des Howtos schon im Wiki vorhanden. vielleicht würde es auch reichen, die/eine FAQ entsprechend anzupassen? Rainer
|
ibu
(Themenstarter)
Anmeldungsdatum: 21. März 2006
Beiträge: 551
Wohnort: Berlin
|
@dee Klar, bleibt es jeden User freigestellt, ob er die Konsole oder die grafische Paketverwaltung nutzen möchte. Daher ist es nicht verkehrt, wenn jeweils die Nutzung von Adept/ Synaptic zusätzlich beschrieben wird. Ich wollte mich zunächst in der Skizze auf die Konsole beschränken. Die Bedienoberflächen der grafischen Paketverwaltungen ändern sich mit der Zeit. Daher erstmal anfangen mit einer präzisen Schritt-für-Schritt-Anleitung für die Konsole. Zur Firefox-Lastigkeit: Ich wollte die Anleitung als Beispiel ausführen. Damit das Beispiel wirklich gleichzeitig auch als präzise Anleitung für die Firefox-Installation dienen kann, empfand ich die Firefox-spezifischen Teile als notwendig. Aber ich möchte darauf nicht beharren. Wenn ihr das anders seht: kein Problem. Dass nicht jedes Paket in den Quellen steht ist klar. Ich wollte alle Eventualitäten abprüfen. Wenn dies gar nicht nötig ist und durch die Existenz eines Paketes mit einer älteren Versionen später bei Upgrades keine Schäden durch Versehen entstehen können: umso besser. Dann können diese Punkte "Paket deaktivieren, Paket aus sources.list entfernen" entfallen. Wenn jedoch eine, wenn auch nur geringe Wahrscheinlichkeit existiert, dass Schäden entstehen können, plädiere ich für das Beibehalten der Punkte. Zu 10-12 Wenn es nicht nötig ist, umso besser. Ich habe die Skizze angepasst. Ist es so besser? Zur Pfadvariable Was ist bei einer Installation aus Paketen üblich? Ich habe den Punkt von Fredo übernommen, der ihn empfahl. Ich habe die Skizze aktualisiert: http://borumat.de/kubuntu-ubuntu-tipps.php#firefox-installieren
|
pippovic
Anmeldungsdatum: 12. November 2004
Beiträge: 9130
|
Hab das mal nach "Rund ums Wiki" verschoben. Es geht ja um eine Wikianleitung. Du solltest vielleicht mit dem Entwurf unter Baustelle beginnen. Gruß pippovic
|
ibu
(Themenstarter)
Anmeldungsdatum: 21. März 2006
Beiträge: 551
Wohnort: Berlin
|
pippovic hat geschrieben: Hab das mal nach "Rund ums Wiki" verschoben. Es geht ja um eine Wikianleitung. Du solltest vielleicht mit dem Entwurf unter Baustelle beginnen.
Du hast Recht. Hier passt das Thema besser. Mit dem Editieren von Wikiartikeln bin ich noch unerfahren. Ist es möglich standardkonformes XHTML strict, das ist das Format meiner aktuellen Skizze mit einem Werkzeug in die Wikisyntax umzuwandeln. Das wäre generell praktisch, wenn man HTML-Bruchstücke in das Wiki übernehmen kann ohne alles neu auszeichnen zu müssen.
|
Blattlaus
Anmeldungsdatum: 29. März 2006
Beiträge: 1399
|
Ich finde den Ansatz auch recht unglücklich. Es soll doch darum gehen, wie man Software ohne Hilfe von apt (und damit auch Synaptic) installiert. Dazu muss man zwingend die Konsole bemühen. Ich finde man sollte den Artikel in 2 Teile unterteilen: a) Software die als statisches Paket vorliegt b) Software die im Quelltext vorliegt zu a) Hier ist es im Prinzip mit runterladen, auspacken und an die richtige Stelle kopieren getan, grob wäre das in etwas:
Herunterladen der Software aus eine belibiegen Quelle (und das kann ja ruhig per Browser passieren) Auspacken der Datei. Das geht auch wieder per GUI (file-roller) oder per Kommandozeile Kopieren an die richtige Stelle (afaik wäre /opt die beste Wahl)
zu b) Das ist schon etwas kniffeliger, da man alle abhängigkeiten per Hand auflösen muss. Grob würde das ganze so ablaufen: Voraussetzung: - build-essentials installiert - bereitschaft etwas Zeit aufzuwenden - meist: Englisch zum lesen der Readme - DIE README LESEN!
make aufrufen und durchlaufen lassen (Das kann je nach größe der Software lange dauern...Gaim 2.0 braucht auf einem 3000+ gut 4 Minuten) sudo make install (installiert die Kompilierten Sachen in die richtigen Verzeichnisse) Software mittels <name> auf der Konsole starten Optional: Starter im Menu anlegen
Ist natürlich lange nicht fertig, sondern nur eine grobskizze...und gerade aus Teil B könnte man sogar einen eigenen Wikiartikel machen.
|
Zero
Anmeldungsdatum: 28. September 2005
Beiträge: Zähle...
|
Ich würde auch sagen, das du die Anleitung auf das Notwendigste beschränken solltest. Blattlaus Vorschlag ist da schon recht brauchbar. Ergänzend würde ich noch einen Sym-Link setzen damit sich das Programm von überall her aufrufen läßt. Ich persönlich lege fertige Binaries immer unter /usr/local ab und dann einen Sym-Link nach /usr/local/bin. Blattlaus hat geschrieben:
zu b) Das ist schon etwas kniffeliger, da man alle abhängigkeiten per Hand auflösen muss. Grob würde das ganze so ablaufen: Voraussetzung: - build-essentials installiert - bereitschaft etwas Zeit aufzuwenden - meist: Englisch zum lesen der Readme - DIE README LESEN!
make aufrufen und durchlaufen lassen (Das kann je nach größe der Software lange dauern...Gaim 2.0 braucht auf einem 3000+ gut 4 Minuten) sudo make install (installiert die Kompilierten Sachen in die richtigen Verzeichnisse) Software mittels <name> auf der Konsole starten Optional: Starter im Menu anlegen
Kleine Anmerkung meinerseits dazu. ./configure würde ich immer mit -prefix=/usr/local aufrufen. checkinstall statt make install benutzen. checkinstall baut ein deb, so das man das Programm auch wieder sauber entfernen kann. Das deb ist allerdings nicht zum weitergeben gedacht, da keine Abhängigkeiten berücksichtigt werden. Davon abgesehen gibt's da schon im Wiki: Programme_compilieren 😉
|
ibu
(Themenstarter)
Anmeldungsdatum: 21. März 2006
Beiträge: 551
Wohnort: Berlin
|
Blattlaus hat geschrieben:
a) Software die als statisches Paket vorliegt b) Software die im Quelltext vorliegt zu a) Hier ist es im Prinzip mit runterladen, auspacken und an die richtige Stelle kopieren getan, grob wäre das in etwas:
Herunterladen der Software aus eine belibiegen Quelle (und das kann ja ruhig per Browser passieren) Auspacken der Datei. Das geht auch wieder per GUI (file-roller) oder per Kommandozeile Kopieren an die richtige Stelle (afaik wäre /opt die beste Wahl)
Herunterladen und Auspacken ist sicher unkritisch. Über die Wahl der richtigen Stelle scheint jedoch keine Einigkeit zu herrschen. Firefox, z.B. kann nicht upgedated werden, wenn er nicht im $home liegt. Immer wieder findet man Vorschläge, dass Recht angepasst werden sollten. Und nicht zuletzt geht es um einen bequemen Zugriff. Das war ja BTW der Anlass für meine Skizze. Fredo erwähnte, dass er dafür die PATH-Variable nutzt. Grundsätzlich halte ich eine Anleitung zunächst mal allein mit der Konsole für attraktiv, weil sie länger gültig bleibt als die Anleitungen für das Vorgehen mit grafischen Werkzeugen. Aber wie gesagt: als Ergänzung ist die Beschreibung des Vorgehens mit grafischen Werkzeugen nützlich. Nochmal zu meinem Grundmotiv: die Anleitung soll den präzise darüber aufklären, welche Konsequenzen, welches andere Detailverhalten (Beispiel: Aufrufen aus der Konsole, Aufrufen aus dem KMenü, was passiert, wenn später die gleiche Anwendung über ein Paket installiert wird, muss eine bereits installierte ältere Version deinstalliert werden etc.) der Nutzer zu erwarten hat, wenn er die Anwendung aus einem Archiv heraus nutzt - im Vergleich zur Nutzung von einer normalen Paketinstallation. Es mag so sein, dass "in aller Regel" nicht viel zu beachten ist. Mir liegt jedoch daran, die Randbedingungen herauszukitzeln, die möglicherweise doch zu Widrigkeiten führen können. Noch ein Punkt: der Nutzer soll sich nichts merken müssen. Klingt trivial, aber ich halte es ergonomisch für äußerst bedeutsam. Die Installationsweise soll später ein problemloses Deinstallieren ermöglichen, auch wenn der Nutzer sich nicht mehr an Details seines Vorgehens erinnert. Meine Skizze habe ich angepasst und die Recherche, ob das erwünschte Paket wirklich nicht existiert, abgetrennt. Zu b) kann ich nichts beitragen. Das scheint eine noch ungleich komplexere Aufgabe zu sein. Toll, wenn auch dazu eine leicht verständliche "bombensichere" Schritt-für-Schritt-Anleitung herauskommt.
|
Unki
Anmeldungsdatum: 23. März 2005
Beiträge: 5761
Wohnort: Essen
|
Andreas Borutta hat geschrieben: Mit dem Editieren von Wikiartikeln bin ich noch unerfahren.
Kein Problem, man kann es ja lernen ... Andreas Borutta hat geschrieben: Ist es möglich standardkonformes XHTML strict, das ist das Format meiner aktuellen Skizze mit einem Werkzeug in die Wikisyntax umzuwandeln.
Eher nicht. es gibt aber einen Konverter, der aus HTML den Moin-Syntax generiert Rainer
|
Zero
Anmeldungsdatum: 28. September 2005
Beiträge: Zähle...
|
Andreas Borutta hat geschrieben:
Herunterladen und Auspacken ist sicher unkritisch. Über die Wahl der richtigen Stelle scheint jedoch keine Einigkeit zu herrschen. Firefox, z.B. kann nicht upgedated werden, wenn er nicht im $home liegt. Immer wieder findet man Vorschläge, dass Recht angepasst werden sollten. Und nicht zuletzt geht es um einen bequemen Zugriff. Das war ja BTW der Anlass für meine Skizze. Fredo erwähnte, dass er dafür die PATH-Variable nutzt.
So wie ich dich verstehe willst du ein allgemeines Vorgehen aufzeigen. Da ist der Firefox dann aber so ziemlich das schlechteste Beispiel, da er viele Sonderfälle bietet. Selbständiges Update, Plugins, Profile. Abgesehen davon gibt es für den Firefox auch schon eine Anleitung im Wiki. Wenn du allgemein vorgehen willst, dann hast du nunmal recht wenige Schritte. - Download (ich würde da eher den Weg über den Browser für Neulinge wählen) - Entpacken in ein Verzeichnis (ob man da nun lieber das eigene /home, /opt oder /usr/local verwendet muß jeder selber entscheiden, da gibt es nichts allgemeingültiges) - Sym-Link oder Eintrag in den Pfad (ebenfalls je nach belieben, ich bevorzuge die Sym-Links) - passende Rechte setzen (normalerweise nicht notwendig) Mehr ist eigentlich nicht zu tun. Alles weitere sind Spezial-Fälle die von Programm zu Programm verschieden sind/sein können. Irgendwie verkomplizierst du das Ganze auch ein wenig obwohl du es doch einfach halten willst, oder!? Grundsätzlich bin ich allerdings auch der Meinung das der User verstehen muß was er da tut. Schritt für Schritt Anleitungen sind ja ganz nett, aber nicht sonderlich hilfreich wenn man nicht begreift was genau da gemacht wird und warum. Wenn man das nicht versteht, ist es sinnlos. Letztendlich gibt es auch nicht einen richtigen Weg. Viele Wege führen zum Ziel. Einige sind nicht unbedingt optimal, aber das sollte für den Anfang auch ersteinmal egal sein. Wichtig ist das Verstehen. Der Rest kommt mit der Zeit.
|
droebbel
Anmeldungsdatum: 19. Oktober 2004
Beiträge: 5388
|
Ohne jeden Post im Detail gelesen zu haben (überflogen hab ich alles), möchte ich anmerken: 1. Installation aus den Quellen dafür existiert bereits eine Anleitung. Die hier gemachten Vorscläge zum Thema sind teilweise dort schon enthalten, teilweise auch nicht ganz korrekt bzw. unausgereift (z.B. make install ohne checkinstall). Bitte schaut Euch Programme_compilieren an, und macht Verbesserungsvorschläge dazu. 2. Zur Installation von Programmen aus Binärpaketen (im tar.*-Format) existiert noch keine allgemeine Anleitung. Der Inhalt kann eigentlich sehr sehr simpel sein: Angabe des korrekten Ziels (/opt) und Hinweis auf die Notwendigkeit, die Menüs manuell zu bearbeiten (→ Menüeditor). 3. Der Firefox sollte aus diesen Artikel herausgehalten werden. FF ist in mancher Hinsicht einigermaßen speziell. 4. Der Sonderfall "neuere Version eines Programms, das bereits in den Quellen vorhanden ist wird normalerweise über die Backports gelöst. Auch hier ist die beschriebene FF-Installation eher die Ausnahme von der Regel und insofern für einen Beispielartikel untauglich. Gruß David
|
ibu
(Themenstarter)
Anmeldungsdatum: 21. März 2006
Beiträge: 551
Wohnort: Berlin
|
Unki hat geschrieben: Andreas Borutta hat geschrieben: Ist es möglich standardkonformes XHTML strict, das ist das Format meiner aktuellen Skizze mit einem Werkzeug in die Wikisyntax umzuwandeln.
Eher nicht. es gibt aber einen Konverter, der aus HTML den Moin-Syntax generiert
Der Link ist zur Zeit nicht erreichbar. Aber ganz verstehe ich Deine Antwort nicht. Das Wiki basiert auf MoinMoin. Es gibt einen Konverter HTML2MoinMoinSyntax. Warum sagst Du dann "eher nicht"? Was denkst Du denn zu so einem Mechanismus als Anregung? So eine Art einfachen Befehl für Wikischreiber "Füge HTML aus Zwischenablage als MoinMoin ein". Natürlich habe ich als Nicht-Programmierer keinerlei Vorstellung, ob so viel oder wenig Zeit benötigt. Sieh es bitte nur als Anregung an.
|
ibu
(Themenstarter)
Anmeldungsdatum: 21. März 2006
Beiträge: 551
Wohnort: Berlin
|
@Zero OK. Wenn FF wirklich so besonders ist, dann taugt er nicht als Beispiel. Ich dachte der einzige Unterschied zu anderen Anwendungen sei seine Option zum Update aus der Anwendung heraus. Ein Profil entspricht ja exakt den Konfigurationsdateien einer jeden Anwendung. Insofern dachte ich, der Unterschied sei gering. Deine Vermutung, dass ich verkomplizieren möchte, trifft nicht zu. Ich möchte, dass der Nutzer bei jeden Schritt der Anleitung begreift warum dieser sinnvoll ist und welche Auswirkungen er hat. Mein Anliegen entstand, weil existierende Anleitungen IMHO eher simplifizieren und den Nutzer mit der sich aufdrängenden Fragestellung "Welche Nachteile hat eigentlich konkret eine Installation aus einem Archiv gegenüber einer Installation aus einem Paket?" Weiterhin ist ein Anliegen meiner Skizze, dass die Anwendung systemweit zur Verfügung steht. Die Skizze habe ich weiter verfeinert und die Ziele genauer aufgeführt. http://borumat.de/kubuntu-ubuntu-tipps.php#firefox-installieren Meiner Ansicht nach kommen solche Dinge bisher zu kurz im Wiki. Auch Fredos Verfahren mit der Path-Variable zum bequemen Zugriff. Oder Fragen wie "Was ist wenn vor der Installation eine alte Version existierte? Was wenn später eine neue über die Paketverwaltung installiert wird?" IMHO sind das bedeutende Fragen, die nicht verkomplizieren, sondern der Klärung zum Verständnis und zur Transparenz beitragen kann. Aber ich möchte nichts weiter als anregen. Wenn ihr meint, das ist so nicht sinnvoll: kein Problem.
|
ibu
(Themenstarter)
Anmeldungsdatum: 21. März 2006
Beiträge: 551
Wohnort: Berlin
|
droebbel hat geschrieben: 2. Zur Installation von Programmen aus Binärpaketen (im tar.*-Format) existiert noch keine allgemeine Anleitung. Der Inhalt kann eigentlich sehr sehr simpel sein: Angabe des korrekten Ziels (/opt) und Hinweis auf die Notwendigkeit, die Menüs manuell zu bearbeiten (→ Menüeditor).
Uff. Das ist ja eine Hiobsbotschaft. Gilt dies auch für Firefox? droebbel hat geschrieben:
3. Der Firefox sollte aus diesen Artikel herausgehalten werden. FF ist in mancher Hinsicht einigermaßen speziell.
OK. Das war mir nicht klar. Ich bat ja schon Zero um Beispiele. droebbel hat geschrieben:
4. Der Sonderfall "neuere Version eines Programms, das bereits in den Quellen vorhanden ist wird normalerweise über die Backports gelöst. Auch hier ist die beschriebene FF-Installation eher die Ausnahme von der Regel und insofern für einen Beispielartikel untauglich.
Ich sehe es nicht als Sonderfall an, dass irgendwann in der Paketverwaltung eine höhere Version bereitsteht als der Nutzer einmal als Binärpaket installiert hat. Wenn das völlig unproblematisch ist, um so besser. Im Zentrum der Anleitung zu den Binärpaketen sollte IMHO eine genaue Auflistung sämtlicher Nachteile stehen, die dem Nutzer entstehen, wenn er aus dem Archiv statt aus dem Paket installiert. Meine Grundannahme ist: umsonst sind Maintainer von Paketen nicht konservativ eingestellt. Aber mir fehlt die Erfahrung die gesamten Nachteile wirklich zu überblicken.
|