Naja, es gäbe noch firefox-bin, libreoffice-bin und vorkompilierte JREs. Man könnte also tatsächlich auch binaries bekommen, allerdings sind im portage vermutlich wirklich nur 4 oder 5 binaries (abgesehen von firmwareblobs oder unfreien Grafiktreibern). Ansonsten fehlt die Gentoo/LFS-Option allerdings.
Ich bin um die *-bin ganz froh. Früher dachte man es wäre schlimm KDE zu kompilieren. Heute sind *office, Firefox und Chromium ganz andere Hausnummern. So manches hat einen Punkt erreicht, wo ich nicht mehr verstehe 'warum'. Das Kompilieren braucht heute insgesamt auch nicht weniger Zeit als früher. Nur früher hatte ich 1 GHz und 512 MB RAM. Heute habe ich 3-GHz-Vierkern, 8 GB RAM und eine SSD. Wenn die Software nun merklich toller geworden wäre, dann würde ich den Mehraufwand beim Kompilieren ja irgendwie verstehen. Aber den funktionalen Unterschied in den vergangenen 15 Jahren kann man mit der Lupe suchen.
Bei EOL-Distros wie Debian Squeeze ist das nicht mehr generell so, da ja keine neuen Sicherheitsupdates mehr herauskommen. Aktuell lassen sich dabei noch die meisten Debian-Wheezy-Pakete aus Wheezy-Sicherheitsaktualisierungen nach Squeeze zurückportieren und das geht oft nur übers Kompilieren.
Es ist eher ein zunächst gar nicht so beabsichtigtes Interesse am Debian-Paketbauprozess. Ich hatte bisher Opensuse 11.4 und 13.1 bis zum Evergreen-LTS-Ende benutzt und wollte mich nach Alternativen umschauen und da bin ich bei Debian Wheezy und Squeeze hängen geblieben.
Ein Problem war dabei der Ausfall von Dri1-OpenGL in Wheezy, weil ich noch eine alte R128-Grafikkarte in einem meiner Alt-Rechner einsetze. Dabei kam heraus, dass nur die R128-Mesa3D-Treiber fehlten, ein einfaches Kopieren aus Squeeze nach Wheezy an die richtige Stelle half sofort.
Dann fragte ich mich, ob xorg in Squeeze dann letztlich dasselbe macht wie mein xorg in Wheezy, also installierte ich Squeeze parallel auf meinem Hauptrechner, um die originären Logfiles nachlesen zu können. Da mein Desktoprechner aber am Internet hängt, habe ich dann noch u.a. den Kernel, Bind und ein paar Libs in Squeeze aktualisiert. Dabei bin ich auf das Multiarchproblem gestoßen und lernte dabei einiges über control- und rules-Files.
Dazu kommen Tests rein aus Neugier, z.B. ob der Gdm2 aus Squeeze einfach so unter Wheezy läuft. Und ja, Gdm2 läuft.
Das gleiche Spiel wiederholte ich mit Abiword 2.8.6 und siehe da, das Abiword 2.8.6 läuft klaglos unter Wheezy. Das Gleiche mit E16 aus Squeeze. Umgekehrt läuft das von mir unter Wheezy kompilierte Kernel 3.2.87-deb-Paket einfach so unter Squeeze.
Ein aktueller Test mit Debian Jessie läuft einigermaßen erfolgreich, d.h. der Exa-R128-Treiber funktioniert so einigermaßen. Man sieht aber, dass man in Zukunft ohne kms-fähigen R128-Grafiktreiber nicht mehr wirklich viel weiterkommen wird.
Fazit: Debian ist flexibler und damit interessanter als ich dachte. Zudem wird hier über Entscheidungen diskutiert. D.h., es befiehlt niemand auf der Mailing-Liste einfach so, das nun die 32bit-Architektur quasi ab sofort eingestellt wird.
Das kann ich nicht für meine Distrie bestätigen. Hier läuft Manjaro KDE und ich bin restlos zufrieden damit. Ich hab noch nie so ein tolles und absolut rundlaufendes KDE erlebt!
Seit 11 Jahren bei gentoo kompilieren, jeden Tag. Habe sogar unter cygwin einzelne Anwendungen kompiliert in der Arbeit, für das Command Line Interface.
Danach habe ich unter OSX oder jetzt Mac OS weiterhin kompiliert. Baue auch selbst Pakete für CentOS/RHEL d.h. kompilieren, rpm erstellen, in das Repository usw.
Wenn es keine ebuillds gibt dann git clone ./configure --help usw.
Umgebung für rpmbuild einrichten, dauert inkl suchen nach Basis Dokus 5 Minuten, möglichst einfaches src.rpm runter laden und installieren - Niemals als root Pakete bauen - Das Prinzip sollte man unter Fedora innerhalb einer Stunde gebacken bekommen
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
dank des Werkzeuges poudriere, was in einer jail Pakete baut, ohne die bauende Maschine selbst mit Abhängigkeiten zu zu müllen, baue ich mir für die FreeBSD Maschinen in unserem Heimnetzwerk ein lokales Repo.
Macht Spaß, man kann Options der zu bauenden Pakete einfach anpassen und hat ein sauber gebautes lokales Repo.
Ich bin von PC auf ARM SBC umgestiegen, nun habe ich das Problem das Software oft nicht kompiliert oder danach nicht funktioniert. deshalb verzichte ich aufs kompilieren und nehme fertige Pakete. Ist weniger stressig und hat auch mit Faulheit zu tun...
Ich bin von PC auf ARM SBC umgestiegen, nun habe ich das Problem das Software oft nicht kompiliert oder danach nicht funktioniert. deshalb verzichte ich aufs kompilieren und nehme fertige Pakete. Ist weniger stressig und hat auch mit Faulheit zu tun...
Nunja, eigentlich fehlt noch die Antwort
- ja, ausschließlich aus Paketquellen
Bei Gentoo ist das ja Standard.
Naja, es gäbe noch firefox-bin, libreoffice-bin und vorkompilierte JREs. Man könnte also tatsächlich auch binaries bekommen, allerdings sind im portage vermutlich wirklich nur 4 oder 5 binaries (abgesehen von firmwareblobs oder unfreien Grafiktreibern).
Ansonsten fehlt die Gentoo/LFS-Option allerdings.
Ich bin um die *-bin ganz froh. Früher dachte man es wäre schlimm KDE zu kompilieren. Heute sind *office, Firefox und Chromium ganz andere Hausnummern. So manches hat einen Punkt erreicht, wo ich nicht mehr verstehe 'warum'. Das Kompilieren braucht heute insgesamt auch nicht weniger Zeit als früher. Nur früher hatte ich 1 GHz und 512 MB RAM. Heute habe ich 3-GHz-Vierkern, 8 GB RAM und eine SSD. Wenn die Software nun merklich toller geworden wäre, dann würde ich den Mehraufwand beim Kompilieren ja irgendwie verstehen. Aber den funktionalen Unterschied in den vergangenen 15 Jahren kann man mit der Lupe suchen.
99% der Programme für den normalen User werden aus den Paketquellen bezogen.
Klappt auch bei Fedora (+rpmfusion).
Bei EOL-Distros wie Debian Squeeze ist das nicht mehr generell so, da ja keine neuen Sicherheitsupdates mehr herauskommen. Aktuell lassen sich dabei noch die meisten Debian-Wheezy-Pakete aus Wheezy-Sicherheitsaktualisierungen nach Squeeze zurückportieren und das geht oft nur übers Kompilieren.
Darf man fragen was der Grund für den Squeeze-Einsatz ist?
Es ist eher ein zunächst gar nicht so beabsichtigtes Interesse am Debian-Paketbauprozess. Ich hatte bisher Opensuse 11.4 und 13.1 bis zum Evergreen-LTS-Ende benutzt und wollte mich nach Alternativen umschauen und da bin ich bei Debian Wheezy und Squeeze hängen geblieben.
Ein Problem war dabei der Ausfall von Dri1-OpenGL in Wheezy, weil ich noch eine alte R128-Grafikkarte in einem meiner Alt-Rechner einsetze. Dabei kam heraus, dass nur die R128-Mesa3D-Treiber fehlten, ein einfaches Kopieren aus Squeeze nach Wheezy an die richtige Stelle half sofort.
Dann fragte ich mich, ob xorg in Squeeze dann letztlich dasselbe macht wie mein xorg in Wheezy, also installierte ich Squeeze parallel auf meinem Hauptrechner, um die originären Logfiles nachlesen zu können. Da mein Desktoprechner aber am Internet hängt, habe ich dann noch u.a. den Kernel, Bind und ein paar Libs in Squeeze aktualisiert. Dabei bin ich auf das Multiarchproblem gestoßen und lernte dabei einiges über control- und rules-Files.
Dazu kommen Tests rein aus Neugier, z.B. ob der Gdm2 aus Squeeze einfach so unter Wheezy läuft. Und ja, Gdm2 läuft.
Das gleiche Spiel wiederholte ich mit Abiword 2.8.6 und siehe da, das Abiword 2.8.6 läuft klaglos unter Wheezy. Das Gleiche mit E16 aus Squeeze. Umgekehrt läuft das von mir unter Wheezy kompilierte Kernel 3.2.87-deb-Paket einfach so unter Squeeze.
Ein aktueller Test mit Debian Jessie läuft einigermaßen erfolgreich, d.h. der Exa-R128-Treiber funktioniert so einigermaßen. Man sieht aber, dass man in Zukunft ohne kms-fähigen R128-Grafiktreiber nicht mehr wirklich viel weiterkommen wird.
Fazit: Debian ist flexibler und damit interessanter als ich dachte. Zudem wird hier über Entscheidungen diskutiert. D.h., es befiehlt niemand auf der Mailing-Liste einfach so, das nun die 32bit-Architektur quasi ab sofort eingestellt wird.
Nein, nein, es heißt "Kopulieren"!
Und ja, ich kopuliere selbst. Wenn auch selten mit Paketen.
Das heißt Nukular! Nu! Ku! Lar!
Cheers,
demon
D'oh!
Weil die Pakete der Distributionen weder ideal (Abhängigkeitshölle) noch aktuell sind.
Das kann ich nicht für meine Distrie bestätigen. Hier läuft Manjaro KDE und ich bin restlos zufrieden damit. Ich hab noch nie so ein tolles und absolut rundlaufendes KDE erlebt!
Habe mich damit noch nicht befasst weiß nicht mal wie das geht.
dass ich noch ein kompiliertes k3b vom Herrn Schily auf diesem Wheezy-Rechner habe. War vor Jahren wohl das letzte Mal, dass ich sowas gemacht habe.
Seit 11 Jahren bei gentoo kompilieren, jeden Tag. Habe sogar unter cygwin einzelne Anwendungen kompiliert in der Arbeit, für das Command Line Interface.
Danach habe ich unter OSX oder jetzt Mac OS weiterhin kompiliert. Baue auch selbst Pakete für CentOS/RHEL d.h. kompilieren, rpm erstellen, in das Repository usw.
Wenn es keine ebuillds gibt dann git clone ./configure --help usw.
Hallo,
Kannst du mal bitte einen Link für eine gute Einführung
zur Erzeugung von rpm's posten?
Wäre sehr nett!
Danke.
Jan
Umgebung für rpmbuild einrichten, dauert inkl suchen nach Basis Dokus 5 Minuten, möglichst einfaches src.rpm runter laden und installieren - Niemals als root Pakete bauen - Das Prinzip sollte man unter Fedora innerhalb einer Stunde gebacken bekommen
Mich macht die %prep-Sektion in den *.spec noch schwach
Was genau ist das Problem? Du brauchst nicht jede sektion in voller Ausbaustufe für jedes Paket
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
Hallo,
dank des Werkzeuges poudriere, was in einer jail Pakete baut, ohne die bauende Maschine selbst mit Abhängigkeiten zu zu müllen, baue ich mir für die FreeBSD Maschinen in unserem Heimnetzwerk ein lokales Repo.
Macht Spaß, man kann Options der zu bauenden Pakete einfach anpassen und hat ein sauber gebautes lokales Repo.
Viele Grüße,
Holger
Ich bin von PC auf ARM SBC umgestiegen,
nun habe ich das Problem das Software
oft nicht kompiliert oder danach nicht funktioniert. deshalb verzichte ich aufs
kompilieren und nehme fertige Pakete.
Ist weniger stressig und hat auch mit Faulheit zu tun...
Ich bin von PC auf ARM SBC umgestiegen,
nun habe ich das Problem das Software
oft nicht kompiliert oder danach nicht funktioniert. deshalb verzichte ich aufs
kompilieren und nehme fertige Pakete.
Ist weniger stressig und hat auch mit Faulheit zu tun...
Also bei mir macht das der Computer mit einem Kompiler:-)