# Stirbt GENTOO gerade ?

## artbody

Stirbt GENTOO gerade ?

Diese Frage stelle ich jetzt mal ganz bewußt hier ins Forum.

GRUND der provokativen Aussage:

 *Quote:*   

> Datum: 25.10.2017: Luka: Dein zmq.hpp ist zu alt, siehe auch https://www.mikrocontroller.net/topic/417908#5187138
> 
> Inzwischen ist sogar in debian stable ne neuere Version drin...

 

also schon über ein Jahr   :Confused:   :Shocked:   :Crying or Very sad: 

 *Quote:*   

> >>> Failed to emerge sci-mathematics/geogebra-5.0.339.0_p20170308-r1, Log file:

 

geogebra ist version 6 <- !  SECHS  ! aktuell 

.......  :Embarassed:   :Rolling Eyes:   :Twisted Evil: 

auch hier seit Version 4 auf 5 dasselbe Problem 

naja sabayon hat geogebra 4.x   :Laughing: 

Gentoo WAR vor Jahren  eine der wenigen Linuxe welche so gut wie immer alles aktuell hatten.

HEUTE ist ein ZUSTAND zu beobachten an dem nicht mal unstable ** hilft um an manche aktuelle Software zu kommen.

DOCH woran liegt es denn, dass da nichts mehr geht ?

Sind alle inzwischen nur noch am Apps für's Handy  proggen ODER windoofiziert

ODER liegt es daran dass ein "Gemeinsam sind wir stark" inzwischen Mangelware ist?

Jeder Entwickler sein eigenes Projekt im Alleingang ganz nach vorne bringen will usw...

Irgendwo hatte ich mal gelesen 

Egoismus wird Linux zerstören.

Sind wir jetzt an dem Punkt ?

Anmerkung : Die Umfrage geht 30 Tage

----------

## firefly

 *artbody wrote:*   

> Stirbt GENTOO gerade ?
> 
> Diese Frage stelle ich jetzt mal ganz bewußt hier ins Forum.
> 
> GRUND der provokativen Aussage:
> ...

 

Bezüglich net-libs/cppzmq gibt es in portage die version 0_pre130717-r1 (unstable) gut möglich dass es mit dieser funktioniert.

Und net-libs/zeromq gibt es in portage in der version 4.3.0 und das ist auch die aktuellste release version davon.

Von deinen beiden Beispielen sehe ich da jetzt nichts was für ein "gentoo stirbt" sprechen würde.

Besonders da nur in dem für dich relevanten bereich nicht mehr die aktuellsten Versionen so schnell auftauchen.

----------

## artbody

Ich habe erst mal ein klares JA gestimmt.

Was ich sehe ist, u.a. dass es Portage an einem Automatismus mangelt, 

- welcher neue Packete automatisch mit in unstable einbindet und entsprechende ebuilds erstellt. 

- # also u.a. ebuild aus git automatisch erzeugt

- # ebuild aus rpm oder deb packeten automatisch generiert

- welcher Fehler beim Kompilieren vom User automatisch an den entsprechenden Maintainer schickt.(wenn vom user freigeschaltet)

- welcher dem Maintainer die Möglichkeit gibt diese Fehler an die entsprechenden Developer weiter zu leiten.(zwangsweise, weil wenn 1000de Fehlermails im Postfach liegen müsste es auch dem intelligentesten EGODEV einleuchten dass er Mist gebaut hat)

Das derzeitige Bild zeigt eindeutig, dass es an "fachlich versierten Packetbetreuern mangelt" sagen die Einen

ODER genauer auf den Punkt gebracht

Portage derart viel Resourcen an  "fachlich versierten Packetbetreuern" benötigt, um der ganzen Flut von Programmen auch nur ansatzweise Herr zu werden.

Resourcenfresser:

Sind aber auch zu langsames Feedback. Hier im Forum tauchen oft Probleme auf, werden gelößt und bis die Lösung dann, irgendwann, in die entsprechenden Packete eingeht, bei Entwicklern und/oder Packetbetreuern umgesetzt wird... vergeht sehr viel Zeit.

In dieser Zeit müssen dann 1000de User alle diese Workarounds ausführen. 

Rechnet man mal 1Stunde pro Problem, vom Erscheinen des Fehlers...bis zum finden und lösen des Problemes , pro User , so wären das 1000 Stunden Manpower.

Überflieger sind hier in meinen Augen QT, Python, Perl .... Updates 

WIE VIELE STUNDEN PRO USER ?  :Rolling Eyes:   :Crying or Very sad: 

Als nächsten Punkt hab ich noch das Problem von "Stable Gentoo"   :Laughing: 

in welchem sich auf einem normalen Rechner, mit der Zeit, bereits ab Erstinstallation (nvidia ..blender, freecad...) soviel ** ~amd ... im package.accept_keywords ansammelt, dass es eigentlich unmöglich ist ein reines Stable Gentoo zu haben. 

 :Arrow:  was dann natürlich wie man an 1000de Threads hier im Forum erkennen kann, immer wieder zu Problemen führt.

 :Idea:   :Idea:   :Idea: 

Bei soviel Manpower wird es doch langsam Zeit diese sinnvoll zu nutzen anstatt sich als Devoloper und Packetbetreuer ... hinter einer EGO-Mauer der Unzugänglichkeit zu verstecken.

----------

## artbody

 *firefly wrote:*   

>  *artbody wrote:*   Stirbt GENTOO gerade ?
> 
> Diese Frage stelle ich jetzt mal ganz bewußt hier ins Forum.
> 
> GRUND der provokativen Aussage:
> ...

 

```
 net-libs/cppzmq

      Latest version available: 0_pre150606

      Latest version installed: 0_pre150606

      Size of files: 4 KiB

      Homepage:      https://github.com/zeromq/cppzmq

      Description:   High-level CPP Binding for ZeroMQ

      License:       MIT

```

Lukas Aussage vom 25.10.2017 bezog sich auf 0_pre150606

----------

## artbody

Und noch ein Punkt

z.B.

ENLIGHTENMENT   :Arrow:  Orginalversion flog durch die FEINDLICHE ÜBERNAHME von Entlightenment17, 18, 19, 20 .. jetzt gerade 22 einfach raus   :Question: 

dazu gibt es hier im Forum auch ein paar Threads.

In meinen Augen ist das Entlightenment17...22.. ein völlig anderes Ding als das Orginal Enlightenment 16 (e16) hätte also NIE gemeinsam geslottet werden dürfen, sondern hätte unter eigenem Namen geführt werden müssen

z.B.Enlightenment17 oder wie auch immer 

ein emerge -s enlightenment

```
  x11-wm/enlightenment

      Latest version available: 1.0.17

      Latest version installed: [ Not Installed ]

      Size of files: 2.361 KiB

      Homepage:      https://www.enlightenment.org/

      Description:   Enlightenment Window Manager (e16)

      License:       BSD

```

DA STEHT   :Arrow:  (e16) IST ES ABER NICHT   :Exclamation:   :Exclamation:   :Exclamation: 

```
 ls /usr/portage/x11-wm/enlightenment

enlightenment-0.22.3.ebuild  enlightenment-0.22.4.ebuild  files  Manifest  metadata.xml
```

Wenn man das installiert bekommt man den "neuen" aber nicht mehr den schlanken schnellen orginal enlightenment.

```
 emerge -av x11-wm/enlightenment

!!! Section 'localrepo' in repos.conf has name different from repository name 'enlighted' set inside repository

 * IMPORTANT: 2 news items need reading for repository 'gentoo'.

 * Use eselect news read to view new items.

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild  N     ] dev-lang/lua-5.1.5-r4::gentoo  USE="deprecated readline -emacs -static" ABI_X86="32 (64) (-x32)" 217 KiB

[ebuild  N     ] dev-libs/efl-1.20.7-r1::gentoo  USE="X bmp eet fontconfig gif ico nls opengl pdf ppm psd pulseaudio sdl sound ssl svg systemd tiff -avahi -connman -dds -debug -doc -drm -egl -examples -fbcon -fribidi -gles -glib -gnutls -gstreamer -harfbuzz -hyphen -ibus -ivi -jpeg2k -libressl -libuv -luajit (-neon) -physics (-pixman) -postscript -raw -scim -static-libs -tga -tslib -unwind -v4l -valgrind -vlc -vnc -wayland -webp -xcf -xim -xine -xpm -xpresent" 63.975 KiB

[ebuild  N     ] x11-wm/enlightenment-0.22.3:0.17/0.22.3::gentoo  USE="acpi nls pam systemd udisks -connman -doc -wayland" ENLIGHTENMENT_MODULES="appmenu backlight battery bluez4 clock conf conf-applications conf-bindings conf-dialogs conf-display conf-interaction conf-intl conf-menus conf-paths conf-performance conf-randr conf-shelves conf-theme conf-window-manipulation conf-window-remembers cpufreq everything fileman fileman-opinfo gadman geolocation ibar ibox lokker luncher mixer msgbus music-control notification packagekit pager pager-plain quickaccess shot start syscon sysinfo systray tasks teamwork temperature tiling time vkbd winlist wireless wizard wl-buffer wl-desktop-shell wl-drm wl-text-input wl-weekeyboard wl-wl wl-x11 xkbswitch xwayland" 25.048 KiB

Total: 3 packages (3 new), Size of downloads: 89.238 KiB

Would you like to merge these packages? [Yes/No] 
```

NO

Da gibt es noch zig Beispiele wo es in meinem Verständnis doch so manche Ungereimtheiten gibt (Gnome Mate...systemd ... )

Ich bin jetzt weit über 10 Jahre mit Gentoo dabei und was ich sehe ist ein immer mehr zunehmendes CHAOS

----------

## mike155

Ich finde diesen Thread reichlich merkwürdig und ärgerlich!

Ich kann es gut verstehen, dass jemand frustriert ist, weil es im offiziellen Portage Tree keinen aktuellen ebuild für ein Programm gibt. Und es ist auch völlig in Ordnung, hierzu einen Thread auf den Foren zu eröffnen. Meines Erachtens wurden hier auch gute Antworten gepostet:

Hu hat erklärt, warum es keinen keinen ebuild gibt

Es gab einen Link auf einen Bug-Report mit einem ebuild für eine neuere Version

fedeliallalinea hat sogar einen ebuild für die aktuelle Version von cppzmq entwickelt und gepostet.

Was will man mehr? Sind das Zeichen für eine sterbende Distribution? Oder sind das eher Zeichen für eine aktive und hilfsbereite Community?

Gentoo lebt davon, dass Leute die Ärmel hochkrempeln und mitmachen! Diskussionen darüber, ob Gentoo gerade stirbt, helfen nicht weiter.

Also mein Vorschlag: ein oder zwei Nachmittage investieren und lernen, wie man ebuilds schreibt und einen lokalen Overlay installiert. Es kostet etwas Zeit, sich da reinzuarbeiten - aber es ist nicht wirklich schwer. Das vorbildliche Beispiel von fedeliallalinea zeigt, dass es kein Hexenwerk ist.

----------

## artbody

Ich habe oben nicht behauptet dass die Community nicht hilfsbereit ist.

Ich habe bis jetzt hier im Forum eigentlich immer gute Erfahrungen gemacht.

 :Very Happy: 

----------

## Max Steel

Mir fehlt ein "Nein" als Auswahl. So sieht das ganze echt nur nach rumgeflenne eines einzelnen aus.

----------

## asturm

Ein Thread wie ein BILD Artikel.

----------

## misterjack

Was für ein manipulativer dummer Thread. Wo ist die Option "Nein" zum Abstimmen?

Edith:

 *Max Steel wrote:*   

> So sieht das ganze echt nur nach rumgeflenne eines einzelnen aus.

 

 *asturm wrote:*   

> Ein Thread wie ein BILD Artikel.

 

Full Ack!

Edith hat noch was:

Nachdem ich gestern ein wenig gepoltert hab, nun die Begründung zu meinen Nein: Zum einen setze Gentoo im Serverumfeld ein, als Web- und Mailserver, teils virtualisiert etc. Sämtliche benötigte Software ist bis auf ein paar Ausnahmen in Portage vorhanden und auf aktuellen Stand. Des weiteren setze ich Gentoo auf meinen Desktop und Laptop ein. Da das gleiche, in der Regel ist die Software bis auf ein paar Ausnahmen auf den neuesten Stand.

 *artbody wrote:*   

> ein völlig anderes Ding als das Orginal Enlightenment 16 (e16) [...]
> 
> Ich bin jetzt weit über 10 Jahre mit Gentoo dabei und was ich sehe ist ein immer mehr zunehmendes CHAOS

 

Du willst Software von 2003 im Portage haben? Das wäre CHAOS pur!

----------

## Yamakuzure

Also da steckt eine Menge "Blödsinn" drin. Ein "Nein" zum Abstimmen fehlt mir auch.

Ich habe das "Blödsinn" in Anführungszeichen gestellt, da so Manches hier ja auch durch mangelnde Erfahrung oder Wissen kommen kann.

Aber da können wir ja helfen.   :Wink: 

 *artbody wrote:*   

> Stirbt GENTOO gerade ?
> 
> Diese Frage stelle ich jetzt mal ganz bewußt hier ins Forum.
> 
> GRUND der provokativen Aussage:
> ...

 Und wenn du mall in die metadata.xml reingeschaut hättest, wüsstest du, wer dafür verantwortlich ist, und wenn du also auf bugs.gentoo.org per Bump Request anfragen musst. Alternativ kannst du auch direkt eine E-Mail schicken.

Btw: Hast du dir mal die geogebra.org Seite angeschaut? Das ist zum fürchten! Schau mal in das Ebuild rein, SRC_URI ist ein tolles Spektakel! Das Ding ist für jeden Maintainer eine Hölle, in die weder gcc noch clang oder LibreOffice jemals hinkommen werden. Grauenvoll das Zeug!

 *artbody wrote:*   

> Gentoo WAR vor Jahren  eine der wenigen Linuxe welche so gut wie immer alles aktuell hatten.
> 
> HEUTE ist ein ZUSTAND zu beobachten an dem nicht mal unstable ** hilft um an manche aktuelle Software zu kommen.

 

Und das machst du an einer obskuren Software fest, von der die meisten Nutzer hier noch nie etwas gehört haben? Schlau.   :Confused: 

 *artbody wrote:*   

> Was ich sehe ist, u.a. dass es Portage an einem Automatismus mangelt, 
> 
> - welcher neue Packete automatisch mit in unstable einbindet und entsprechende ebuilds erstellt.
> 
> - # also u.a. ebuild aus git automatisch erzeugt
> ...

 Das sind unglaublich ... mir fehlt ein Wort, dass nicht wie "idiotisch" klingt... "wenig sinnvolle" Ideen.

Wie soll denn ein Ebuild aus Git automatisch erzeugt werden? Wie soll so ein automatischer Mechanismus denn feststellen, ob der aktuellste Commit nicht zum Build Breaker geworden ist? Außerdem gibt es haufenweise Live-Ebuilds.

Wie soll denn ein Ebuild aus rpm/deb generiert werden? Das sind Binärpakete, keine Sourcecodes mit Bauanleitung.Wenn du deb/rpm möchtest, installier dir Debian, RedHat oder eines der unendlichen Derivate.

Wie dem auch sei, ich fürchte du hast wenig Ahnung davon, was dazu gehört ein funktionierendes Ebuild zu schreiben.

Diese Seite kann dir ob ihres Umfangs ein klein wenig helfen, den Aufwand besser abzuschätzen, und warum solche Automatismen nicht funktionieren können:

https://devmanual.gentoo.org/ebuild-writing/index.html

 *artbody wrote:*   

> - welcher Fehler beim Kompilieren vom User automatisch an den entsprechenden Maintainer schickt.(wenn vom user freigeschaltet)
> 
> - welcher dem Maintainer die Möglichkeit gibt diese Fehler an die entsprechenden Developer weiter zu leiten.(zwangsweise, weil wenn 1000de Fehlermails im Postfach liegen müsste es auch dem intelligentesten EGODEV einleuchten dass er Mist gebaut hat)

 Um Himmels Willen!

Das wäre die größte Sabotageaktion auf Erden! Hirn aus, Spam an, oder wie?

Was ist mit all den Berichten, die dann rumfliegen, weil ein Spaßvogel in seinen C[XX]FLAGS alle Warnungen aktiviert und wie Fehler behandeln lässt? Hast du mal QtWebengine gebaut? Der Chromium-Code verursacht davon Tausende!

Und wie "An Developer weiterleiten"? Meinst du die Bauen ihre SOftware nie selbst, oder wie?

 *artbody wrote:*   

> Das derzeitige Bild zeigt eindeutig, dass es an "fachlich versierten Packetbetreuern mangelt" sagen die Einen
> 
> ODER genauer auf den Punkt gebracht
> 
> Portage derart viel Resourcen an  "fachlich versierten Packetbetreuern" benötigt, um der ganzen Flut von Programmen auch nur ansatzweise Herr zu werden.

 Das ist einfach nur dummes Zeug. Sorry, aber da fällt mir nichts höfliches mehr zu ein.

 *artbody wrote:*   

> Resourcenfresser:
> 
> Sind aber auch zu langsames Feedback. Hier im Forum tauchen oft Probleme auf, werden gelößt und bis die Lösung dann, irgendwann, in die entsprechenden Packete eingeht, bei Entwicklern und/oder Packetbetreuern umgesetzt wird... vergeht sehr viel Zeit.

 Falsch. Das Problem ist, dass hier im Forum auftauchende Lösungen auf Seite X/Vielen nicht weitergegeben werden. Dafür gibt es BugZilla. Erwartest du, dass die Developer alle Threads flöhen? Wann sollen die das denn noch machen?

 *artbody wrote:*   

> Überflieger sind hier in meinen Augen QT, Python, Perl .... Updates

 Jeder ist anders und jedes System ist unterschiedlich. Das letzte Mal, als ich Schwierigkeiten mit Qt oder Perl hatte, war, glaube ich, 2016. Ich verwende übrigens Qt-5.11.3 und Perl-5.26.2.

 *artbody wrote:*   

> Als nächsten Punkt hab ich noch das Problem von "Stable Gentoo"  
> 
> in welchem sich auf einem normalen Rechner, mit der Zeit, bereits ab Erstinstallation (nvidia ..blender, freecad...) soviel ** ~amd ... im package.accept_keywords ansammelt, dass es eigentlich unmöglich ist ein reines Stable Gentoo zu haben.

 Werden keine Stable Requests gestellt, wird auch nichts stabilisiert. Wer dann meint mit ~amd64 mischen zu müssen, weil ein Bugreport mit Stable request ja (mal wieder) zu viel verlangt ist, ist selber Schuld.

Ich verwende seit Jahren ACCEPT_KEYWORDS="~amd64" in meiner make.conf, und habe seit genau so vielen Jahren nur ein einziges Problem gehabt: Subversion-1.11.0 kommt nicht mehr mit der GitHub SVN-Bridge zurecht. Ansonsten ist ein Eintrag in /etc/portage/package.mask nun wirklich kein Beinbruch, aber in deienn Augen mal wieder zu viel verlangt?

 *artbody wrote:*   

> Bei soviel Manpower wird es doch langsam Zeit diese sinnvoll zu nutzen anstatt sich als Devoloper und Packetbetreuer ... hinter einer EGO-Mauer der Unzugänglichkeit zu verstecken.

 Bugzilla und E-Mail. Und wenn es ganz dringend ist, mach es selbst und öffne einen Pull Request.

Aber irgendwelches tolles Zeug im Forum zu "verstecken", um dann den Devs anzukreiden, sie hätten das nicht ASAP umgesetzt, ist richtig?

Wenn all die Manpower, die aufs Meckern und Jammern verwendet würde, mal in Bug Reports, Pull Requests und Feedback (welches nicht in X Seiten versteckt ist) verwendet würde, ginge alles viel schneller.

Alle Developer und alle Proxy Maintainer sind Freiwillige, die kostenlos ihre Freizeit opfern.

----------

## forrestfunk81

Ich würde auch gerne mit einem klaren Nein stimmen! Bitte füge die Option doch noch nachträglich hinzu.

Ich setze Gentoo seit 2005 ein und es wurde von Jahr zu Jahr stabiler. Als ich damals mit ~amd64 startete war eine 64bit Installation wirklich noch experimentell, kein Vergleich zu unstable heute. Alle paar Monate schlägt jetzt mal ein Build fehl. Oft reicht es dann am nächsten Tag zu synchronisieren und die Fehler sind behoben. Wenn nicht muss man halt mal einen Bug Report aufmachen.

Nach fast 14 Jahren unstable habe ich diese Woche meine letzte Installation auf stable umgestellt - einfach weil es mir zuviele Minor- und RC- Updates sind. Von den 1217 installierten Paketen auf meinem Arbeitslaptop sind weniger als 50 unstable (hauptsächlich Browser und Development Sachen). Und ob ich jetzt KDE Plasma 5.14.3 (stable) oder 5.14.4 (unstable) laufen habe ist mir ziemlich egal.

Über die Jahre hinweg hatte ich Gentoo auf knapp 30 Geräten am Laufen - von Raspberries und Router über day2day Arbeits- und Entwicklungslaptop bis zum VServer, welcher wieder LXC Container mit Gentoo Installationen hält. Dementsprechend unterschiedlich sind/waren die Use Cases und Paket Anforderungen. Außer Eclipse, JProfiler und GitKraken hab ich nichts an Portage vorbei installiert.

Im Gegenteil, ich bin sehr positiv überrascht, dass Gentoo im Bereich moderner Software-Entwicklung so breit aufgestellt ist. Von Docker über AWS SDK, Minikube, Helm, Terraform etc ist alles da, was man für die Cloud so braucht. Und das Top aktuell! Die Updates kommen hier meist schneller rein, als bei den Ubuntu Kollegen.

Deshalb an dieser Stelle ein großes Lob und vielen Dank an die Devs und Maintainer <3

----------

## Marlo

 *forrestfunk81 wrote:*   

> ...vielen Dank an die Devs und Maintainer 

 

++

----------

## misterjack

 *Yamakuzure wrote:*   

> Ich verwende seit Jahren ACCEPT_KEYWORDS="~amd64" in meiner make.conf, und habe seit genau so vielen Jahren nur ein einziges Problem gehabt: Subversion-1.11.0 kommt nicht mehr mit der GitHub SVN-Bridge zurecht. Ansonsten ist ein Eintrag in /etc/portage/package.mask nun wirklich kein Beinbruch, aber in deienn Augen mal wieder zu viel verlangt?

 

Also ich war jetzt jahrelang mit einem gemischten System unterwegs - Macht der Gewohnheit, die man irgendwann nicht mehr hinterfragt. 594 Einträge in der accepted_kewords, die ich jetzt getrost löschen kann.

```
Emerging (152 of 756)
```

----------

## Yamakuzure

 *misterjack wrote:*   

>  *Yamakuzure wrote:*   Ich verwende seit Jahren ACCEPT_KEYWORDS="~amd64" in meiner make.conf, und habe seit genau so vielen Jahren nur ein einziges Problem gehabt: Subversion-1.11.0 kommt nicht mehr mit der GitHub SVN-Bridge zurecht. Ansonsten ist ein Eintrag in /etc/portage/package.mask nun wirklich kein Beinbruch, aber in deienn Augen mal wieder zu viel verlangt? 
> 
> Also ich war jetzt jahrelang mit einem gemischten System unterwegs - Macht der Gewohnheit, die man irgendwann nicht mehr hinterfragt. 594 Einträge in der accepted_kewords, die ich jetzt getrost löschen kann.
> 
> ```
> ...

 Ich habe auch Jahrelang gemischt. Meine accepted_keywords war ähnlich umfangreich. Aber als ich mit dem "Mischen" angefangen hatte, bedeutete "unstable" auch wirklich "unstable". Heutzutage heißt es eher "neu und noch nicht gegen alles getestet."

"Microsoft kann Millionen Benutzer nutzen um ganze Windows Generationen Beta zu testen, und wir schaffen nicht mal ein paar poplige Pakete?", dachte ich mir dann einst und ging halt komplett auf ~amd64. Hab's bislang nicht bereut.

----------

## ChrisJumper

artbody, mach dir keinen Kopf!

Im Zweifelsfall musst du dich halt einlesen in die Howtos und deine Lieblingspakete selber mit E-Builds versorgen. Im Zweifel fragst du im Chat nach oder bei bugs.gentoo.org!

Speicher, einige Bereiche sind weg, verloren an andere Distributionen und der Ausbau oder die Weiterentwicklung stockt ein wenig. Aber deswegen ist es noch nicht tot. Im Grunde sind die Kern-Elemente weiterhin sehr gut unterstützt und gepflegt. Ich würde mir da keine Sorgen machen, sicher die ein oder anderen Überflüssigen Pakete aus der Hype-Zeit werden aktuell nicht aktualisiert, aber wenn du erst mal verstanden hast warum das so eine Arbeit ist, diese Pakete zu unterstützt (oder ein Paket), weinst du dem auch keine Träne nach.

Die anderen alternativen sind bedeutend schlechter, wie ich finde und im Grunde kann man mit ein paar Skripts und Overlays das ganze sehr erträglich nutzen. Es ist komplizierter als vor zehn Jahren und bei einigen Paketen scheint es ein wenig turbulent zu sein, doch im Grunde stellt dies kein Problem dar.

Weil die Nutzungsszenarien bei anderen proprietären Betriebssystemen oder Dienstleistungen viel schlimmer sind.

----------

## Marlo

 *artbody wrote:*   

> 
> 
>  *Quote:*   >>> Failed to emerge sci-mathematics/geogebra-5.0.339.0_p20170308-r1, Log file: 
> 
> geogebra ist version 6 <- !  SECHS  ! aktuell 
> ...

 

Hmmm,

schau dir das ebuild einmal an: 

```
cat /usr/portage/sci-mathematics/geogebra/geogebra-5.0.339.0_p20170308-r1.ebuild 

```

Ist ja ne tolle Liste an Abhängigkeiten. Übrigens ist  bugs.gentoo.org  zu geogebra ziemlich aktuell. 

Dann hab ich mir mal die  Linux64-Portable-6-0-513-0.zip heruntergeladen und entpackt.

Da ich KDE habe musste ich nur noch  gnome-base/gconf nachinstallieren.

mit einem fröhlichen  

```
./GeoGebra
```

 startet das Teil.

Hmmm,

die zip muss noch nicht mal installiert werden. Die von dir so ersehnte Version 6 startet einfach so.

Brauche ich dafür ein so großen ebuild? Muss ich DAFÜR gentoo als sterbend verdächtigen?

----------

## gorg86

Nein Gentoo liegt nicht im sterben...

Es gibt immer wieder Pakete die vernachlässigt werden, aber da gibts auch genug positive Beispiele.

Z.B. war Blender vor einigen Jahren ein ziemlicher Graus, mitlerweile is alles aktuell und die Installation ist auch einfach.

Um den Atom Editor zu installieren, muss man auch nichtmehr durch Hula-Hoops springen.

----------

## doedel

Diese generelle Anti-Haltung gepaart mit Scheuklappen nimmt man an, wenn man sich zu lange im Dunstkreis von mikrocontroller.net aufhält. Dem Forum hab' ich schon vor Jahren den Rücken gekehrt...

Da kann man rumpissen wie man will und findet immer Rückhalt sowie Gegner - diese "Gesprächskultur" nimmt man dann auch an.

Die Umfrage ist Bildzeitungsniveau. Mir fehlt auch ein eindeutiges nein als Antwort.

... und ich will nicht auf Rechtschreibung herumreiten, das soll ernsthaft konstruktiv sein:

Paket und nicht Packet. Sprich das mal aus: "Pakkett".

----------

## Marlo

 *doedel wrote:*   

> 
> 
> ... und ich will nicht auf Rechtschreibung herumreiten, das soll ernsthaft konstruktiv sein:
> 
> Paket und nicht Packet. Sprich das mal aus: "Pakkett".

 

Das hatten wir mit  Pisa  schon mal.   :Laughing: 

----------

## doedel

Wow, das find' ich cool. Als ich in angesprochenem Mikrocontroller.net Forum noch aktiv war, konnte man einfach nicht posten, wenn man Wiederstand geschrieben hat. Aber vor ein paar Tagen habe ich Wiederstand dort gelesen, vielleicht haben die das wieder abgeschafft.

... Widerstand ...

jetzt sehen beide Varianten, die Richtige und die Falsche, komisch für mich aus... *seltsam*

Jeder macht Fehler, aber manche sind so eindringlich und drücken schon fast im Kopf beim Leser... Ich will damit auch echt niemandem was vorhalten, wie oben schon geschrieben. Packet ist nur sowas, was vielen aufstösst. Das falsch Schreiben degradiert auch niemandem zum Idioten, nur das lernresistent Sein und Anti-Haltung, wenn man drauf aufmerksam gemacht wird.

----------

## ChrisJumper

Es gibt Probleme mit dem Stabilisieren, aber das durchzieht sich denke ich in allen Bereichen.

Das man einfach einen Stabelize-Request als Bug eröffnen darf, wusste ich auch nicht. Ich dachte die Maintainer haben da eh genug zu tun. Zumal es gefühlt auch immer schwieriger wird weil die Abhängigkeiten oft so verzwickt sind. Wenn ich mich da an openssl 1.1 erinnere, was ja auch schon vor Jahren kam und immer noch Maskiert ist, weil die Bibliothek dieses Projektes umfangreichere Änderungen mit sich bringt bei den Programmen die das einsetzen.

Gibt es da eigentlich einen Blog oder News-Seite zu die sich mit diesen Veränderungen Beschäftigt und das schön zusammen fasst, wahrscheinlich kann man das nur in den Bugzilla-Threads oder Dokumentationen lesen.

Mit git hat sich das alles verändert. Auch hier werden eher dezentrale Repositories verwendet wo man dann etwas ausprobiert statt eine gemeinsame Test-Basis zu habe. Richtige Bugs die einen Stören gehen zurück an git oder das Bugzilla vom Projekt.

Ich selber halte mich damit aber immer zurück weil ich kein Vertrauen in meine Test-Umgebung habe, ich denke immer das ist nicht entsprechend normiert oder zu "Unstable/Mixed" und dann würde ein Beitrag eher zur Verwirrung beitragen.

Packett Boden oder ein Päckchen-Paket ist auch ein fieses Wort! Besonders wenn man oft abwechselnd Englisch und Deutsch schreibt geht es im Eifer des Gefechtes unter.

Edit: Jetzt hatte ich noch was wichtiges Vergessen warum ich aber eigentlich schreibe:

Es hat was ekliges, diese Docker-Images und diese Git-Mentalität, vielleicht kommt es mir nur so vor weil ich bei Lineageos noch nicht durch gestiegen bin und Android selbst ein sehr großes Projekt ist.

Aber mir geht es auf den Keks das diese Installations-Routinen oft wirken wie eine Hand voll Skript die sich alles per Git, oder ganz schlimm per hinein kopierten CURL Shell-Befehl ein Skript laden das Abhängigkeiten auflöst.

Im Fall von Lineageos, ist das sehr bequem, ich denke es ist ähnlich wie diese Docker-Images das man sich nicht mehr darum kümmern muss die Pakete für eine bestimmte Distribution zu machen, sondern man Kopiert sein Set einfach von Maschine A auf Maschine B, hat seine eingebundenen Repositories.

Es mag praktisch sein aber ein ungutes Gefühl wenn ich so etwas einsetze habe ich trotzdem. Wahrscheinlich sind dies aber die gleichen Voraussetzungen die Entwickler haben wollen um eine gleiche Basis zu haben.

Doch irgendwas muss ja falsch gelaufen sein. Vor 10 Jahren hielte ich diese Linux-Paket-Vewaltung, auch wenn sie nicht komplett einheitlich ist. Immer für eine sehr gute Idee. Doch es hat sich nun mal nicht durch gesetzt.

Die ganzen Programmier- und Skript-Sprachen bringen ihre eigene Paketverwaltung mit (Perl, Python, Ruby, Nodejs ist denke ich so etwas ähnliches..). Mir kommt es ein wenig so vor als wurde das Rad X mal neu Erfunden und implementiert aber es gibt kein Einheitliches Tool. Vielleicht ist GIT aber auch das einheitliche Tool, aber dann frage ich mich warum diese Art die Paketverwaltung noch nicht komplett abgelöst hat. Git ist ja auch quasi ein rsync, mit dem Zusatz der Versionsverwaltung. Dennoch wird rsync oft verwendet. Wobei ich oft denke das viele Menschen github Nutzen um Daten zu synchronisieren und Bereit zu stellen.

Es könnte ja so einfach sein wenn alle ein einheitliches Tool verwenden, wie bei der Paketverwaltung von einer Distribution. Gleichzeitig ist die Pflege wohl zu speziell und Aufwendig. Für viele liegt die Antwort auf dies Frage wohl in den Container-Images oder in der Nutzung eben dieser Overlays, statt dem Standard-Mechanismus der Paketverwaltung selbst. Es hat ja durchaus Vorzüge, und Konfigurationsfehler lassen sich vermeiden. Aber es wirkt befremdlich auf mich wenn die gute Praxis um sich zum Beispiel einen Mastodon Server zu installieren, einfach das Docker-Image ist, statt eine detaillierte Beschreibung über den Aufbau und die Dienste.

Im Grunde wird Komplexität immer nur mit einer größeren Box drum herum erschlagen, nur damit man wieder bei dem .exe Paket landet das einfach ein paar Klicks braucht. ;D

Ich sehe ein Muster und stelle mir vor das dies bei Vim/Emacs aber auch bei Systemd so war... doch wenn man sich eine Grafikkarte oder einen WLAN-Treiber anschaut, merkt man sehr schnell das die Komplexität überhand nimmt. Aber auch das war ja schon bei Prozessoren so und zum Beispiel der Intel-ME.

Die gute Alternative sind wohl nur Systeme mit möglichst wenig Speicher, CPU und Akkuleistung. Die voraussetzen möglichst Sparsam mit allem um zu gehen.

----------

## doedel

Zu Andoid und anderen "Paketen", die als "Paket" verteilt werden...

Andoid habe ich vor zig Jahren auf einem Core2Duo gebaut, das hat hat Tage gedauert, aber mein S2 hatte dann mein Android.

Das ist eine komplette build-Umgebung, die alle libraries beinhaltet. Da kommt ein Compiler mit, bestimmte, gepatchte libraries, viel viel eigener Kram, ...

Da ist es die einzig wartbare Möglichkeit, einen riesen Ordner zu schaffen, in den man entweder per chroot reingeht oder per cd und dann ein build-script ausführt. Ist bei buildroot, openembedded und anderen auch so.

Ich habe mal code für ein Nokia N900 compiliert, da kam die Toolchain in einer fertigen VM. Ich glaube sogar, das war gentoo. Kann man ich aber auch irren. Das finde ich "ein wenig oversized". Dein Beispiel mit dem Mastodon Server kann ich gut nachvollziehen. Das gleiche mit einer VM für einen Compiler. Es mag wartbar sein und bei Nokia vielleicht auch so verwendet werden, mit Vorteilen... Aber hätte man nicht einfach ein Paket vom Compiler schnüren können?

Das ist für mich sehr unsauber im Hinblick auf das laufende Gesamtsystem (ein Server, beim Desktop gibt es sicher ähnliche Sünden...).

Immer wenn mir tools wie Paketmanager einer Scriptsprache oder so begegnen, dann habe ich da auch immer komisches Gefühl dazu. Ich kann nicht genau sagen warum, vielleicht sogar nur die Faulheit ("Schon wieder was neues...").

Git führt metadaten über alle Änderungen und braucht so echt viel Platz. rsync ist da einfacher und in vielen Fällen schon mehr als ausreichend. Persönlich habe ich lieber, wenn in solchen Umgebungen rsync, wget und curl arbeiten, als mit git-repos. Aber das ist echt nur Geschmackssache, begründen kann ich das nicht...

Der einzige für mich "saubere Weg" um sowas Unsauberes zu machen, wie an der Paketverwaltung vorbei ist das nutzen von Ordnern im /home-Ordner oder unter /opt.

Das einzige was da "rausgehen" darf, sind ein paar symlinks.

Gerade habe ich das Beispiel mit dem open-watcom compiler. Dort gibt es ein 350mb dicken Ordner mit compilern für DOS, Windows/ 8086-386 und AXP. Jede Host-Architektur hat einen Unterordner. Ich packe den also nach /opt/ow und füge /opt/ow/bin64l zum Pfad hinzu.

Andere Programme wie eagle oder vmware machen das auch so.

Ebenso aufgebaut, nur für jeweils 1 Host System, sind die arm-toolchains von ARM und anderen Anbietern oder cegcc für Windows CE targets.

Man kann solche "blobs" auch sauber aufziehen, wie man daran sieht. Finde ich...

----------

## forrestfunk81

Die Programmiersprachen-Paketverwaltungen oder besser Buildsysteme sind halt Entwickler- und Release- Tools. Niemand möchte eine große Anwendung mit vielleicht Hunderten von transitiven Abhängigkeiten ohne diese Tools erstellen. Der Usecase, dass Endanwender ihre Binaries selbst kompilieren, ist bei diesen Buildtools einfach nicht vorgesehen oder out of scope. 

Und ja, es ist sehr schade, dass die Integration in Portage so schwierig ist. Ich habe lange Zeit die X Versuche verfolgt, Maven in Portage zu integrieren. Aber das ist der Tatsache geschuldet, dass bei Gentoo alles kompiliert wird. Debian und Co können einfach die Binaries nehmen, die von Maven ausgespuckt werden. Aber bei Source Distros gibt es dann zwei Tools, die sich um die Paketabängigkeiten kümmern wollen. Dass diese Build Tools so einen Edge Use Case nicht berücksichtigen, kann man ihnen denke ich nicht vorwerfen. Denn das wofür sie geschrieben wurden, machen sie ganz gut.

Bei den Docker Installationen bin ich etwas zwiegespalten. Das Prinzip nur noch ein paar Config Files zu haben und die einzuchecken (configuration as code) finde ich super. Man kann einfach zurückrollen oder auf andere Maschinen ausweichen. Man hat ein schön abgeschottetes System, welches sich immer gleich verhält und wenn man den Container weg wirft, bleibt auch nichts auf dem Host zurück. 

Allerdings traue ich "dem Internet" nicht und würde keinesfalls irgendwelche Container bestehend aus 10 oder mehr Layern installieren, wo man nicht weiß was da alles mitkommt. Es ist allerdings auch kein Hexenwerk die Dinger selbstzubauen.

Und wer "curl -s http ://unknown.website.com/dubious.sh | bash -s --" ausführt ist selbst schuld   :Very Happy: 

----------

## l3u

 *mike155 wrote:*   

> Also mein Vorschlag: ein oder zwei Nachmittage investieren und lernen, wie man ebuilds schreibt und einen lokalen Overlay installiert. Es kostet etwas Zeit, sich da reinzuarbeiten - aber es ist nicht wirklich schwer. Das vorbildliche Beispiel von fedeliallalinea zeigt, dass es kein Hexenwerk ist.

 

So mach ich das seit Jahren … und poste das Ergebnis auf b.g.o. Mittlerweile bin ich auch Proxy-Maintainer. Muss man wollen, aber Gentoo muss man ja schließlich auch wollen :-P

----------

## franzf

 *l3u wrote:*   

>  *mike155 wrote:*   Also mein Vorschlag: ein oder zwei Nachmittage investieren und lernen, wie man ebuilds schreibt und einen lokalen Overlay installiert. Es kostet etwas Zeit, sich da reinzuarbeiten - aber es ist nicht wirklich schwer. Das vorbildliche Beispiel von fedeliallalinea zeigt, dass es kein Hexenwerk ist. 
> 
> So mach ich das seit Jahren … und poste das Ergebnis auf b.g.o. Mittlerweile bin ich auch Proxy-Maintainer. Muss man wollen, aber Gentoo muss man ja schließlich auch wollen 

 

Wobei ich sehe, dass patches/ebuilds auf b.g.o vermehrt ignoriert werden, muss man jetzt alles per PR auf github machen, wozu ich irgendwie keine Lust habe...

----------

## Yamakuzure

 *franzf wrote:*   

>  *l3u wrote:*    *mike155 wrote:*   Also mein Vorschlag: ein oder zwei Nachmittage investieren und lernen, wie man ebuilds schreibt und einen lokalen Overlay installiert. Es kostet etwas Zeit, sich da reinzuarbeiten - aber es ist nicht wirklich schwer. Das vorbildliche Beispiel von fedeliallalinea zeigt, dass es kein Hexenwerk ist. 
> 
> So mach ich das seit Jahren … und poste das Ergebnis auf b.g.o. Mittlerweile bin ich auch Proxy-Maintainer. Muss man wollen, aber Gentoo muss man ja schließlich auch wollen  
> 
> Wobei ich sehe, dass patches/ebuilds auf b.g.o vermehrt ignoriert werden, muss man jetzt alles per PR auf github machen, wozu ich irgendwie keine Lust habe...

 Ich lade alle Ergebnisse in mein eigenes Overlay, denn jeder User kann sich eines beantragen, und dann gibt es drei Möglichkeiten:

Ich lasse das dort versauern, weil es sowieso niemanden interessiert, bzw. die Software nicht im Portage Tree drin ist.

Ich bin Proxy-Maintainer für das Paket, also bringe ich meine Erkenntnisse in meinen Gentoo Fork ein, und öffne einen Pull Request. Als Proxy-Maintainer weiß ich ja, wen ich anpingen muss.

Ich mache ein diff zwischen dem Original und meinem Update, und lade den erzeugten Patch auf b.g.o., denn dort will man Patches und nicht ebuilds.  :Wink: 

Das klingt nach viel Aufwand. Ist es auch. Spätestens seit man nichts mehr pushen kann, wenn der "Signed-Off-By:"-Hinweis in der Commit-Nachricht fehlt, oder die E-Mail-Adresse darin nicht hinterlegt ist.

...und ich habe das immer noch nicht automatisiert... *schäm*

Aber ich finde es inzwischen gut so. Denn auch wenn der "Einstiegsaufwand", bis so eine Aktualisierung mal ankommt, recht hoch erscheint, ist es gar nichts im Vergleich zu den schier endlosen Diskussionen und Nachbesserungen nach früher möglichen etwaigen "Schnellschüssen". Ich habe selber ein paar davon losgetreten....

----------

