Bei kleinen Programmen mag das vielleicht möglich sein. Meine letzten Versuche sind bei Debian, Hadoop und Octave kläglich gescheitert. Ich habe in Octave ein Bug gefunden, die Stelle im Sourcecode behoben und versucht es zu kompilieren, um zu testen ob sich das Verhalten wirklich verbessert. Das hat dann einen halben Tag gedauert und ich musste es aufgeben.
Wer ein durchdachtes, standardisiertes und durchgeprüftes Buildsystem erwartet ist bei Linux komplett falsch. Größere Programme setzen sich heute aus unzähligen Bibliotheken zusammen. Diese haben meist anarchistische Build Scripts. Das finale Programm ist das genau so beschissen zu kompilieren. Ohne frickeln sieht man heute so gut wie überhaupt kein Build Success. Ich spreche hier nicht von MultiArch Builds, mit CygWin oder so. Das ist noch eine Nummer hässlicher.
Das ist auch der Grund weshalb sich Docker und VM's immer weiter durchsetzen. Der Maintainer ist meist der einzige, der weiß wie das Programm richtig kompiliert wird. Er erstellt VM's und Docker Container, die dann genutzt werden.
Schlimm ist es weil es immer weniger möglich ist, das Verhalten eines Programmes zu überprüfen...
Schön ist es sicherlich nicht. Aber solange es Distributionen gibt und diese die Software abpacken ist eigentlich sichergestellt, dass auch neben dem Maintainer jemand existiert, der weiß wie man die Software bauen kann.
Aber dieses Schichten auf Schichten gestapel hat auch meiner Ansicht nach einen unschönen Punkt erreicht. Flachere Abhängigkeiten und weniger Wiederbenutzung würden an einigen Stellen sicher zur Einfachheit beitragen.
so sehr ich linux im desktop bereich kritisiere - auf commandline fubktioniert das compilieren ansich sehr gut - ibsbedondere sauber aufgesetzte configure basierte buildscripts.
ubter debian ist es am besten sich einmal ein buildsystem zu installieren - dann kann man das zu patchende paket als src pKet runterziehen ubd mit den debian tools alls compilieren und ein neues deb paket bauen.
das groessere problem ist eher das debian in x wochen dein selbst gebautes deb paket wieder überschreibt wenn du sicherheitsupdates für dieses bekommst.
wer öfters mal was compilieren möchte und/oder die gnu/linux-prinzipien unter in der tiefe verstehen möchte dem kann ich linux-from-scratch (lfs) ans herz legen. von dem dort erworbenem praktischen linux-wissen kann man zeitlebens zehren
Ich weiß nicht, wo genau bei dir das Problem lag. Aber ich habe eher die gegenteilige Erfahrung gemacht. Ich muss dazu sagen, dass ich die Programme die ich bis jetzt selbst kompiliert habe, an einer Hand abzählen kann. Das wären Hal und Sane aus Distributionsquellen (Debian) und KToshiba und Freshplayer aus den Originalquellen. Bei beiden war wirklich alles gut dokumentiert, was das Vorgehen bzw. die Abhängigkeiten angeht. Wie aufwendig es ist, hängt dann halt von der gewählten Methode ab, von der Größe des Programms und wie schnell man die jeweiligen Bibliotheken/Header-Files in den Repositories der eigenen Distribution findet (wenns hart auf hart kommt, findet man seine Antwort via Google; aber das Problem hatte ich bei den 2 Programmen, die ich aus den Originalquellen kopiliert hatte, bis jetzt nur ein Mal).
Wenn das Buildsystem von Octave nicht durchdacht und sorgfältig sinnvoll eingestellt ist, wird das wohl auch ein bisschen an den Devs von Octave liegen oder? Und nur teilweise an den für Linux verfügbaren Buildsystemen an sich.
Ich baue regelmäßig sehr aufwändige Anwendungen mit sehr vielfältigen Abhängigkeiten ohne Probleme. Mit waf und verschiedenen Varianten von configure/make unter Ubuntu 16.04
Bei kleinen Programmen mag das vielleicht möglich sein. Meine letzten Versuche sind bei Debian, Hadoop und Octave kläglich gescheitert. Ich habe in Octave ein Bug gefunden, die Stelle im Sourcecode behoben und versucht es zu kompilieren, um zu testen ob sich das Verhalten wirklich verbessert. Das hat dann einen halben Tag gedauert und ich musste es aufgeben.
Wer ein durchdachtes, standardisiertes und durchgeprüftes Buildsystem erwartet ist bei Linux komplett falsch. Größere Programme setzen sich heute aus unzähligen Bibliotheken zusammen. Diese haben meist anarchistische Build Scripts. Das finale Programm ist das genau so beschissen zu kompilieren. Ohne frickeln sieht man heute so gut wie überhaupt kein Build Success. Ich spreche hier nicht von MultiArch Builds, mit CygWin oder so. Das ist noch eine Nummer hässlicher.
Das ist auch der Grund weshalb sich Docker und VM's immer weiter durchsetzen. Der Maintainer ist meist der einzige, der weiß wie das Programm richtig kompiliert wird. Er erstellt VM's und Docker Container, die dann genutzt werden.
Schlimm ist es weil es immer weniger möglich ist, das Verhalten eines Programmes zu überprüfen...
Schön ist es sicherlich nicht. Aber solange es Distributionen gibt und diese die Software abpacken ist eigentlich sichergestellt, dass auch neben dem Maintainer jemand existiert, der weiß wie man die Software bauen kann.
Aber dieses Schichten auf Schichten gestapel hat auch meiner Ansicht nach einen unschönen Punkt erreicht. Flachere Abhängigkeiten und weniger Wiederbenutzung würden an einigen Stellen sicher zur Einfachheit beitragen.
so sehr ich linux im desktop bereich kritisiere - auf commandline fubktioniert das compilieren ansich sehr gut - ibsbedondere sauber aufgesetzte configure basierte buildscripts.
ubter debian ist es am besten sich einmal ein buildsystem zu installieren - dann kann man das zu patchende paket als src pKet runterziehen ubd mit den debian tools alls compilieren und ein neues deb paket bauen.
das groessere problem ist eher das debian in x wochen dein selbst gebautes deb paket wieder überschreibt wenn du sicherheitsupdates für dieses bekommst.
wer öfters mal was compilieren möchte und/oder die gnu/linux-prinzipien unter in der tiefe verstehen möchte dem kann ich linux-from-scratch (lfs) ans herz legen. von dem dort erworbenem praktischen linux-wissen kann man zeitlebens zehren
Ich weiß nicht, wo genau bei dir das Problem lag. Aber ich habe eher die gegenteilige Erfahrung gemacht. Ich muss dazu sagen, dass ich die Programme die ich bis jetzt selbst kompiliert habe, an einer Hand abzählen kann. Das wären Hal und Sane aus Distributionsquellen (Debian) und KToshiba und Freshplayer aus den Originalquellen. Bei beiden war wirklich alles gut dokumentiert, was das Vorgehen bzw. die Abhängigkeiten angeht. Wie aufwendig es ist, hängt dann halt von der gewählten Methode ab, von der Größe des Programms und wie schnell man die jeweiligen Bibliotheken/Header-Files in den Repositories der eigenen Distribution findet (wenns hart auf hart kommt, findet man seine Antwort via Google; aber das Problem hatte ich bei den 2 Programmen, die ich aus den Originalquellen kopiliert hatte, bis jetzt nur ein Mal).
Was Octave angeht, hatte ich durch gezieltes suchen, halt das gefunden:
Octave-Dokumentation/Appendix E Installing Octave
Keine Ahnung, ob du schon darüber gestolpert warst.
Wenn das Buildsystem von Octave nicht durchdacht und sorgfältig sinnvoll eingestellt ist, wird das wohl auch ein bisschen an den Devs von Octave liegen oder? Und nur teilweise an den für Linux verfügbaren Buildsystemen an sich.
Ich baue regelmäßig sehr aufwändige Anwendungen mit sehr vielfältigen Abhängigkeiten ohne Probleme. Mit waf und verschiedenen Varianten von configure/make unter Ubuntu 16.04