Jau, aasche... Wenn ich mal so genau wüsste, wie man am besten aufteilen könnte. Ich persönlich halte von Aufteilen nämlich eigentlich gar nichts. Mir stinkt es einfach einen Artikel zu einem Thema zu haben, bei dem ich dann zig weiterführenden Links folgen muss, anstatt einfach das Inhaltverzeichnis benutzen zu können. Aber das bin ich und das hier ist nicht mein Wiki.
Also wenn Aufteilen, dann würde ich sagen, teilt wirklich auf. Ein Übersichtsseite wie z.B. für Paketverwaltung und den jetzigen Artikel stumpf ins Kleinste zerlegen. Dann hätte man mehrere kurze Artikel, die man unabhängig von einander pflegen kann, während man sich dort dann auch nicht scheuen muss mit den Informationen - insbesondere zu den abweichenden Methoden - etwas mehr ins Detail zu gehen bzw. auch weitere Artikel dort zusammenzuziehen. Beispielsweise:
ÜBERSICHT - PROGRAMME KOMPILIEREN
(Ich würde an dieser Stelle dann auch vorschlagen dem Thema einen neuen Namen zu geben, weil prinzipiell beschäftigt sich dieser Artikel eher mit der Installation von Programmen, die nicht in den Paketquellen auftauchen und für die weder ein PPA noch eine andere Quelle für ein Paket besteht, was sich nunmal nicht alleinig auf das Kompilieren beschränkt.)
An dieser Stelle eine Einführung, die ähnlich der Einleitung und dem Abschnitt "Grundlegendes" aus dem jetzigen Baustellen-Artikel gestrickt ist.
Vorbereitung:
Quelltexte ("Quelltextarchive" und "Dokumentation" fusionieren)
Abhängigkeiten auflösen
Gängigste Methoden:
Standard-Methode
Ubuntu-Methode
Debian-Methode
Weitere Methoden:
CMake
QMake
Autotools
Scons
Installtionsskripte (mit "Programme in Skriptsprache fusionieren)
Vorkompilierte Programme
Valider Paketbau:
(Ich nehm hier einfach mal die beiden derzeitigen, auch noch ausbaufähigen Artikel. Letzen Endes hoffe ich ja, dass sich jemand diesem Thema auch mal annimmt und das verständlich in deutscher Sprache ins Wiki einpflegt.)
Paketbau
dh_make
Ich weiss, dass es hiermit auf deutlich mehr Arbeit hinausläuft, aber ich denke auch, dass es ein sehr wichtiges Thema ist, das gut dokumentiert auch weniger versierten Anwender die Möglichkeit bieten kann über den Tellerrand der Paketquellen hinauszuschauen. Zugegeben, als Supporter sieht man das eigentlich nicht gerne, aber es rennen damit schon genug Leute blind ins Verderben, dass sich jeder glücklich schätzen kann, wenn er ohne viele Erklärungen auf einen sauberen Artikel verweisen kann. Ich persönlich sehe es auch lieber, wenn sich Anwender über einen unschuldigen Quelltext hermachen, als wahllos PPAs in die sources.list zu schreiben oder irgendein Paket aus den tiefen des Internets zu zerren.
Wovon ich aber aus Erfahrung abrate, ist eine Art Schnelleinstieg zu schreiben um sowas wie Einsteigerfreundlichkeit zu simulieren. Wenn man sowas anbietet, dann liest kein Mensch mehr die Textteile mit den weiterführenden Informationen und man kann sich die Arbeit auch sparen ausführlich zu dokumentieren. Und sich später so oder so schwarz ägern, wenn die "Einsteiger" sich auf drei Befehle mit Copy&Paste beschränken, ohne zu wissen, was sie da tun.
Eine weitere Diskussion über checkinstall können wir und an dieser Stelle wohl schenken. Es gibt keine Alternative, die so vielseitig Installationsmethoden abfangen kann. Der Hinweis in Richtung quick & dirty muss - wie einige andere Textpassagen - eben nochmal neu formuliert bzw. ergänzt werden. Es sollte nur ausdrücklich klargestellt werden, dass sich Pakete über checkinstall nur für die lokale Anwendung und nicht für die Weitergabe taugen. Ich beharre allerdings weiterhin darauf, dass dieser Ausdruck "fachlich" recht genau das beschreibt, was die Verwendung von checkinstall ist. Mein Vorschlag dahingehend:
Hinweis:
Technisch betrachtet gilt die Verwendung von checkinstall als "quick & dirty". Allerdings überwiegen in Ermangelung einer Alternative die Vorteile dieses Programms dessen Schwächen und seine Verwendung ist damit absolut legitim. Ausdrücklich sei noch einmal darauf hingewiesen, dass die mit checkinstall erstellen Pakete sich nicht für die Weitergabe, sondern nur für den Eigenbedarf eignen.
So, und jetzt Fossball!
