staging.inyokaproject.org

Ich bin soweit durch mit dem Artikel. Jetzt sollte eigentlich alles bishin zur korrekten Syntax stimmen.

Den Hinweis, dass checkinstall "quick & dirty" ist, möchte ich gerne drin behalten, damit es bitte so abschreckend ist, dass keiner auch nur auf die Idee kommt solche Pakete weiterzugeben.

hab ihn jetzt nur schnell überflogen... war das zu cmake eigentlich schon vorhanden? Wenn nein, dann sag ich mal DANKE! Ich werde da wohl noch ein bißchen was eintragen und z.B. erwähnen, dass KDE und Compiz cmake verwenden und ein paar Vorteile nennen. Hänge vllt auch noch mein kleines .bashrc Skript rein, mit dem man sehr schnell und einfach über cmake kompilieren kann (nette Befehle cs und cb um zwischen src und build Verzeichnis zu wechseln und ein Befehl zum direkten bauen und installieren aus dem src Verzeichnis)

martingr, immer rein damit, wenn du noch weitere oder ergänzende Inhalte hast. Umso vollständiger umso besser. Und falls da noch Rechtschreibfehler auftauchen, gleich wegkorrigieren. Das gilt natürlich auch für alle anderen, die noch was zu dem Thema beizutragen haben... Ich weiss da leider (immer noch) nicht alles, was wichtig zu wissen wäre 😉

Und nein, CMake ist wie SCons nicht im alten Artikel enthalten. Die beiden habe ich neu reingenommen.

Puhh.. Der Artikel hat aber jetzt ganz schön zugenommen 😉 Aber es wurde auch wohl Zeit für eine Überarbeitung.

Aber bitte nehmt die ganzen Verlinkungen auf Quelltextverzeichnis raus. Das ist absolut irreführend. Evtll wäre es besser bestimmte Beispielangaben zu benutzen, also zB: "~/Quelltext" und "~/Quelltext/Version". Ist IMHO verständlicher als der Link.

Müssen so viele Alternativen im Artikel stehen? Sehr verwirrend...

Manche Textpassagen sind unverständlich. Beispiel: "In den meisten Installationsanleitungen, die nicht für Ubuntu geschrieben sind, fehlt sudo, ist durch su ersetzt, oder die Befehlszeile mit einem # für "root" gekennzeichnet. Bei Ubuntu muss stets sudo verwendet werden für systemweite Operationen."

Gruß
kaputtnik

Hi!

Ich bin bei checkinstall noch nicht ganz glücklich. Der Hinweis zu "quick and dirty" sollte anders formuliert werden, sodass klarer wird, dass es Probleme dabei geben kann, die Pakete auf anderen Systemen zu nutzen, weil sie nur für von und für das eigene System passend gebaut sind.

Außerdem halte ich dieses hier für irreführend: (aus Ubuntu-Methode- checkinstall)

Der Paketname gewinnt insbesondere an Bedeutung für eine parallele Installation des selbstkompilierten Programms zu einem bereits in der Paketverwaltung^[1] bestehendem Paket. Dafür sollte man den Paketnamen ändern, damit das bestehende Paket nicht überschrieben wird.

Tatsächlich kann dass verwenden eines anderen Namens für das selbe Programm in der Praxis zu Problemen führen, weil ggf. Dateien verwendet werden, die im "Original-Paket" vorhanden sind, und die Installation mit checkinstall bricht mit einer Fehlermeldung ab (etwas wie "kann datei xyz nicht überschreiben, die auch im Paket abc vorhanden ist", weiß den genauen Wortlaut jetzt nicht, könnte es aber nochmal verifizieren).

@ kaputtnik Ich denke auch, dass es sinnvoller wäre, den Artikel aufzuspalten; und die Verlinkungen auf Quelltextverzeichnis müssten wohl wirklich nicht überall sein.; das gilt z.T. auch für andere interne Verlinkungen.

Zu der von dir zitierten Passage: Da müsste man ggf. noch die Syntax etwas ändern, damit klarer wird, was gemeint ist, inhaltlich ist der Hinweis aber völlig ok und sinnvoll.

so lonk
hank

Hi!

Hab' jetzt noch mal "durchgeschliffen"; folgendes fiel mir noch auf:

Quelltextverzeichnis säubern¶

Ein Grund das Quelltextverzeichnis von allen kompilierten Programmteilen zu bereinigen, wäre mit dem configure-Skript die falschen Optionen übergeben zu haben. Ein anderer, dass man das Quelltextverzeichnis nicht gelöscht, sonder zwecks Weiterverarbeitung (z.B. Paketbau) nicht gelöscht hat und nach einem Distributionsupgrade alle Programme gegen neue Versionen der Abhängigkeiten kompilieren muss.

Ist das Quelltextverzeichnis nun gelöscht oder nicht?

Zu der autogen.sh-Frage würde ich eine "ausbaufähig-Box" setzen.

Die Varianten zu cmake, scons (und qmake, was noch fehlt 😉 ...) könnten imho in einen eigenen Unterartikel verschoben werden.

so long
hank

Hallo,

wir wäre es mit einer 3-Teilung:

• Hauptartikel: "klassische Methode

• Unterartikel 1: Ubuntu 7 Debian Methode

• Unterartikel 2: Cmake, scons usw.

Gruß, noisefloor

noisefloor schrieb:

wir wäre es mit einer 3-Teilung:

• Hauptartikel: "klassische Methode

• Unterartikel 1: Ubuntu 7 Debian Methode

• Unterartikel 2: Cmake, scons usw.

👍 Abhängigkeiten auflösen sollte auch ausgelagert werden. Ist build-essentials wirklich eine Abhängigkeit im gemeinten Sinne? Würde eher sagen, das es eine generelle Voraussetzung ist, als eine Programmspezifische Abhängigkeit.

kaputtnik schrieb:

Abhängigkeiten auflösen sollte auch ausgelagert werden.

Nope, das ist so wichtig, dass es auf alle Fälle drin bleiben muss - es gilt für alle Methoden als Grundlage.

Ist build-essentials wirklich eine Abhängigkeit im gemeinten Sinne? Würde eher sagen, das es eine generelle Voraussetzung ist, als eine Programmspezifische Abhängigkeit.

Da erst damit die Werkzeuge zum Kompilieren gestellt werden ist es wohl eher generell, aber es steht ja auch nicht als "programmspezifische Abhängigkeit" da, könnte allerdinngs auch gleich ganz nach oben.

Ansonsten : "make distclean" fehlt noch, kann ich vieleicht heute abend einbauen.

so long
hank

noisefloor schrieb:

wir wäre es mit einer 3-Teilung:

• Hauptartikel: "klassische Methode

• Unterartikel 1: Ubuntu 7 Debian Methode

• Unterartikel 2: Cmake, scons usw.

dann schon eher

• Hauptartikel: Ubuntu Methode

• Unterartikel 1: klassische Methode

• Unterartikel 2: Debian Methode, Cmake, scons usw. - wobei dieser Teil eigentlich in Paketbau bzw. Grundlagen der Paketerstellung gehoeren wuerde...

Der Baustellen-Artikelinhalt in seiner jetzigen Form ist sehr informativ und ausfuehrlich - sprich gut ☺

Allerdings ist er auch ein weiteres Beispiel, wie ein Wiki-Artikel voellig am Ziel vorbeischiessen kann. Wobei ich als Ziel eine "einsteigerfreundliche Erklaerung" definiere. In diesem Fall viel zu lang und viel zu komplex. Und als Linkziel fuer andere Artikel IMHO voellig ungeeignet... immer noch unter der Voraussetzung "einsteigerfreundlich". Eine geeignete Aufteilung ist daher meiner Meinung nach zwingend notwendig.

aasche schrieb:

• Hauptartikel: Ubuntu Methode

• Unterartikel 1: klassische Methode

• Unterartikel 2: Debian Methode, Cmake, scons usw. - wobei dieser Teil eigentlich in Paketbau bzw. Grundlagen der Paketerstellung gehoeren wuerde...

Ich würde dann doch einen eigenen Unterartikel für Cmake vorschlagen, da es immer wieder im KDE Forum Fragen dazu gibt. In dem Fall würde ich auch die von mir weiter oben genannten Scripte mit einfügen (die ich aktuell zurückgehalten habe, da es den Artikel komplett sprengen würde) und man könnte das Bauen eines Plasmoids zeigen (der häufigste Fall im KDE Forum).

Aber ich glaube wir sind uns einig, dass dem Artikel eine Aufteilung in mehrere Unterartikel nicht schaden würde 😉

Hallo,

Allerdings ist er auch ein weiteres Beispiel, wie ein Wiki-Artikel voellig am Ziel vorbeischiessen kann. Wobei ich als Ziel eine "einsteigerfreundliche Erklaerung" definiere.

Das stimmt. Allumfassende Allwissenheit ist meist nicht einsteigerfreundlich. 😉

Und +1 zur Aufteilung von aasche - wir sind schließlich ein Ubuntu-Forum. 😉

Gruß, noisefloor

Hi!

Ich bin mir bei den Aufteilungen noch nicht so sicher. Die "Ubuntu"-Methode via checkinstall sollte zumindest als erste Version behandelt werden; auch wenn AdrianB und cLinx ja eher der Meinung sind, das solle ganz aus dem Wiki verschwinden... ▶ checkinstall-mal-aus-dem-wiki-entfernen

Allerdings sind die Grundlagen dazu ja die gleichen wie bei der "klassischen Methode" - das auseinander zu nehmen ist dann wohl nicht so sinnvoll. Vielleicht kann man zunächst die checkinstall-Methode kurz umreißen, (und das auch so darstellen: "Wer schnell ein Paket für den Eigenbedarf erstellen möchte, ist mit der Methode "./configure, make, sudo checkinstall" meistens gut bedient"), und dann tiefer einsteigen?

so long
hank

@dauerflucher: was haelst Du von all diesen Vorschlaegen?

@Heinrich Schwietering:

Ich bin mir bei den Aufteilungen noch nicht so sicher. Die "Ubuntu"-Methode via checkinstall sollte zumindest als erste Version behandelt werden; auch wenn AdrianB und cLinx ja eher der Meinung sind, das solle ganz aus dem Wiki verschwinden... ▶ checkinstall-mal-aus-dem-wiki-entfernen

Folgende Punkte werden an checkinstall bemaengelt:

• quick & dirty - ja, es soll schnell gehen...

• keine standardkonformen Pakete - ok, spielt aber bei lokaler Verwendung keine Rolle

• nur mit Root-Rechten ausfuehrbar - falsch!

checkinstall bleibt DIE Alternative fuer Leute ohne Vorwissen, um ein Paket zu erzeugen und zu verwenden. Und ist damit immer noch meine Empfehlung, statt via sudo make install Dateien wild ueber das System zu verstreuen. Wer dieses Chaos einmal von Hand reparieren durfte, weiss warum...

Hi!

Ich hab' mit checkinstall auch kein "Problem" (und hatte auch noch keine nicht-lösbaren Probleme damit), verwende es eigentlich immer, wenn ich mir Sache zusammenbaue. Die Frage ist für mich, inwieweit wir eine "Anfänger"-Sektion basteln, die kurz, und ohne weitere Hintergründe, auf denn "Bau"/Installation mit checkinstall eingeht, oder wieviel "Hintergrundwissen" dafür tatsächlich nötig und sinnvoll wäre.

configure und make braucht man ja sowieso, daher könnte man das ja theoretisch stehen lassen, und dann beim Installieren "abzweigen" lassen, in checkinstall, make install etc.

so long
hank