# stable, mixed oder ~arch?

## cryptosteve

Moinsen!

Im Jahr 2003 habe ich mit Gentoo angefangen und damals ein reines stable-System betrieben. Das lief soweit ganz gut, bis mir irgendwann einige wenige Programm in aktuelleren Versionen fehlten. Diese habe ich mir dann einzeln über Portage mit passender Konfiguration ins System gespült, was sich auf Dauer leider als nicht so gute Idee erwiesen hat. Es gab immer öfter Blocks, was mich dann irgendwann schon echt genervt hat.

Schließlich habe ich das System irgendwann auf ~arch gezogen und - mit diversen Unterbrechungen - bis heute so genutzt. Das läuft eigentlich soweit auch ganz gut, aber in letzter Zeit fehlt mir ab und an der Nerv, mich mit neu aufgetretenen Problemen zu beschäftigen. Dann zickt mal das Netzwerk, dann zickt mal suspend, jetzt zickt meine Lenovo-USB-Tastatur trotz seit Monaten unveränderter Kernelconfig. 

Mich würde daher interessieren, welche Systeme ihr so fahrt?! Reines stable, stable + einige wenige gezielt aktualisierte Programme, oder gar ~arch? Ist 'mixed' heute noch ähnlich knifflig wie in 2003/2004? Und wie sieht es mit Sicherheitsupdates von wichtigen Paketen in stable aus? Wie zeitnah werden Firefox, Thunderbird und Chromium stabilisiert? 

Vielen Dank für eure Rückmeldungen vorab ...

----------

## Fijoldar

Hallo,

also ich fahre auf meinen Systemen immer ein Mix aus stable und testing. Dabei halte ich das Kern-Sytem (Kernel, gcc, systemd etc.) möglichst stabil und bei den Deskop-Anwendungen gehe ich dann auf testing (gnome-shell, firefox, Mail-Programme). Das klappt soweit auch ganz gut. Der Wartungsaufwand hält sich sehr in Grenzen. Ab und zu muss mich mal eine Änderung in der package.use oder package.accept_keywords durchführen, weil sich eine Abhängigkeit geändert hat. Das ist aber kaum der Rede wert.

Wenn ich mal Probleme mit meinem System habn, hängt es fast ausschließlich mit den Grafikkarten-Treibern zusammen. Vor allem mit dem Nvidia Treiber, mit dem man dann Programme wie webkit-gtk oder mesa einfach nicht mehr bauen kann. Aber auch der freie Intel Treiber macht in letzter Zeit unglaublich viel Probleme. Da funktioniert auch immer weniger. 

Die am besten funktionierende Kiste ist momentan mein Notebook mit AMD CPU und AMD Grafikkarte. Es ist zwar furchtbar langsam, aber funktioniert einfach  :Smile: .

Was die Updates angeht, so ist das sehr unterschiedlich. Mal gibt es das Firefox Update quasi sofort, bei der nächsten Version wartet man dann mal eine Woche, bis es endlich verfügbar ist. Es gibt da aus meiner Sicht keine klare Linine, wobei Sicherheitskritische Updates immer sehr zeitnah zur Verfügung stehen.

----------

## platinumviper

Ich habe überall mixed Systeme aber nur wenig ~arch, auf diesem Rechner sind es 58 Einträge.

----------

## schmidicom

Bei einem Server so wenig Testing wie möglich und beim Desktop bin ich gern experimentierfreudig. Andere Overlays nutze ich nur ungern, eher kopiere ich das ebuild in mein eigenes lokales Overlay.

----------

## cryptosteve

Ich sage schonmal Danke für die Antworten.

Ich konnte es natürlich nicht abwarten und habe mich am Wochenende gleich daran gemacht, meine ~amd64-Kiste auf stable zu migrieren. Mir war klar, dass das vielleicht ein wenig einfacher werden würde, als eine unmittelbare ~amd64-Installation, aber das es so reibungslos abläuft ... ich hatte in der letzten Zeit desöfteren stable-Kisten (als Server) aufgesetzt, aber inkl. KDE ... das lief hier komplett unterbrechungsfrei durch 

Aktuell habe ich hier nur 7 Libs aus Testing installiert, 6 davon alleine für roger-router und eines für einen paste-Dienst. Klingt bislang vertretbar und ich bin mit der Aktualität meines System trotzdem vollauf zufrieden.

Danke fürs Feedback.

----------

## franzf

@cryptosteve:

Wie hast du das downgrade von glibc auf stable hinbekommen? Das sollte portage eigentlich verbieten (mMn. einer der Hauptgründe, warum mixed sicherer sein sollte als radikal auf ~arch - ein verkorkstes glibc-upgrade und du bist ziemlich aufgeschmissen)

Wg. Firefox: Gentoo setzt seit einiger Zeit nur noch die LTS-Releases auf stable. Die Feature-releases bleiben immer testing. Bugfixes kommen zeitnah und gehen meist sofort stable.

----------

## cryptosteve

 *franzf wrote:*   

> @cryptosteve:
> 
> Wie hast du das downgrade von glibc auf stable hinbekommen? Das sollte portage eigentlich verbieten (mMn. einer der Hauptgründe, warum mixed sicherer sein sollte als radikal auf ~arch - ein verkorkstes glibc-upgrade und du bist ziemlich aufgeschmissen)

 

Sorry, da habe ich mich wohl sauber ausgedrückt. Meine "Migration" bestand in einem neuen cryptsetup der Platte mit anschließendem Format und Neuaufsetzen. Meine altes /etc/portage/* habe ich 1:1 zurück kopiert dann dann einfach bauen lassen.

Ich muss nochmal gucken, ob und wenn ja, welche Altlasten ich da in /etc/portage/* entsorgen muss. Eine package.accept_keywords hatte ich ja bislang nicht, die ist also noch neu, aber speziell package.use ist noch voll mit versionierten Einträgen, die ich so vielleicht gar nicht mehr brauche. Aber wie gesagt, der Build des ganzen Systems ist 1a durchgelaufen und bislang ist mir auch nichts nachteiliges aufgefallen.

 *franzf wrote:*   

> Wg. Firefox: Gentoo setzt seit einiger Zeit nur noch die LTS-Releases auf stable. Die Feature-releases bleiben immer testing. Bugfixes kommen zeitnah und gehen meist sofort stable.

 

Firefox ist nicht ganz so wild, das nutze ich mit eingeschränkten Profilen nur noch für wenige Sachen (ein Profil für SkyGo und AmazonPrime, eines für Facebook, etc.). Mein Stammbrowser ist chromium und den hat's mir in Version 40.0.2214.91 ins System gespült. Das ist weit aktueller als ich das auf den meisten anderen Systemen in der VirtualBox gesehen habe.

----------

## Josef.95

 *cryptosteve wrote:*   

> Ich muss nochmal gucken, ob und wenn ja, welche Altlasten ich da in /etc/portage/* entsorgen muss. Eine package.accept_keywords hatte ich ja bislang nicht, die ist also noch neu, aber speziell package.use ist noch voll mit versionierten Einträgen, die ich so vielleicht gar nicht mehr brauche.

  Tipp: Beim aufräumen könnte eventuell das Tool "enalyze" aus app-portage/gentoolkit helfen.

Beispiel: 

```
$ enalyze rebuild use

  -- Scanning installed packages for USE flag settings that

     do not match the default settings

  -- preparing pkgs for file entries

   - Saving file: /home/josef64/package.use.test

   - Done

```

 Diese ( im home) abgelegte neue package.use.test kann dann als Vorlage (nach prüfung) für die neue verwendet werden.

Diese hilft beim aufräumen i.d.R. schon mal ein ganzes Stück weiter  :Smile: 

----------

## kurisu

Eingangs auf rein auf stable, zeitweise auf ~arch, habe ich schon vor Längerem wieder allmählich zurück auf stable migriert. Weniger bedingt durch konkrete Schwierigkeiten, die durch die hervorragende Arbeit der Devs zuallermeist mit minimalem Aufwand zu bewältigen waren, sondern vielmehr infolge unzureichender Übersichtlichkeit mangels immer weniger werdender Abstecher zu bgo.

Gefolgt dem Zwist um systemd bin ich am Ende über eudev gar zu mdev gelangt. Vielleicht ein radikaler Ansatz, aber ich persönlich fahre damit ganz ausgezeichnet. Denn sofern Claws-Mail, Firefox, eine funktionierende LaTeX-Umgebung, eher simple Entwicklung über gVim sowie rudimentäres Multimedia gewährleistet sind, bin ich vollends zufrieden. Wieso also all die Bloatware und zusätzlichen Sicherheitsrisiken? Und wie schon im anderen Thread durch User mv illustriert, aber auch anderenorts im englischsprachigen Teil des Forums, gibt es auch hier Möglichkeiten, externe Datenträger komfortabel zu mounten.

Bekanntlich lässt einem Gentoo die Wahl. Mit nur einer Hand voll Einträge in /etc/portage/package.accept_keywords, einer wöchentlich durch app-portage/porticron versendeten E-Mail über aktuelle Updates und GLSAs fahre ich mein System ohne wirklichen Wartungsaufwand. Mehr Komfort bei gleichzeitiger Kontrolle geht wohl kaum.

Korrektur: Ich meinte mdev, kein statisches /dev.Last edited by kurisu on Sun Feb 08, 2015 4:36 pm; edited 2 times in total

----------

## mv

Ich fahre soweit wie möglich stable, aber da ich entwickle, bevorzuge ich von gcc, teilweise binutils, und autobloat die jeweils aktuellsten Versionen (bei gcc gerne sogar "**").

Bei bestimmten Anwendungen (kernel, firefox, youtube-dl) ist aus Sicherheits- bzw. Kompatibilitätsgründen sinnvoll, unstable zu haben, und Einiges wie Skype gibt es ja ohnehin nur unstable.

Dies bringt es mit sich, dass mein package.accept_keywords zeitweise ziemlich voll ist: Viele Compilationsfehler mit aktuellem gcc lassen sich nur durch Upgraden auf unstable fixen; die Abkehr von emul-* hat vor einiger Zeit auch viele unstable-Packages erfordert. Inzwischen schrumpft meine package.accept_keywords wieder spürbar.

Meine Hauptgründe, unstable nicht generell zu benutzen, sind zwei:

1. Unstable hat viel Updates als stable; sinnvoll kann man das nur bei sehr rechenkräftigen Maschinen machen, und ich habe aber auch schwächere; lange zwischen den Upgrades zu warten, ist keine Option, weli die Rechner dann ggf. lange offene Sicherheitslücken haben.

2. Ich habe gerne die Möglichkeit, bei Schwierigkeiten eine "alternative" Version zu benutzen. Da erscheint mir ein stable->unstable-Wechsel im Problemfall sinnvoller als umgekehrt ggf. Maskieren im Problemfall, was ggf. weiteres Maskieren nach sich ziehen muss und letztlich zu einem ziemlich chaotischen System führt.

----------

## Marlo

@mv ++

ich habe da eine Erinnerungslücke, hoffe du kannst mir helfen.

Da gab es mal eine Anwendung mit der man seine package.accept_keywords | package.unmask |  package.use |

und so weiter, daraufhin überprüfen konnte, ob sie noch gebraucht werden.

Gibt es sowas noch?

thx

Ma

----------

## Jean-Paul

Wenn ich dich richtig verstanden habe, macht das  *Quote:*   

> eix-test-obsolete

 

----------

## Finswimmer

Hm. Und wie kann ich die gefundenen Änderungen dann in die Dateien schreiben lassen?

----------

## mv

 *Finswimmer wrote:*   

> Hm. Und wie kann ich die gefundenen Änderungen dann in die Dateien schreiben lassen?

 

Das macht eix-test-obsolete bewusst nicht, da nicht alles, was für das Programm eine Redundanz ist, auch vom Anwender als Redundanz empfunden werden muss.

Ich würde so etwas auch nie automatisch von einem Progrmam machen lassen wollen.

Es gibt andere Tools wie portpeek, die so etwas machen, und die stillschweigend davon ausgehen, dass man mit ihrem "Konzept" für Redundanz einverstanden ist. Für mich hatte das nur bedingt Nutzen, weil ich z.B. ungerne nur gewisse Versionen von Paketen freischalte - portpeek geht aber davon aus, dass man das grundsätzlich zu macht.

----------

## Finswimmer

Hey,

danke. Das "Problem" ist nur, dass meine Datei ca. 800 zu entfernende Einträge hat und die auch nicht der Reihe nach in der Datei stehen.

Nun müsste ich für jede Datei die Ausgabe von eix-test-obsolete kopieren, einen diff machen und das dann speichern...

----------

## mv

 *Finswimmer wrote:*   

> Das "Problem" ist nur, dass meine Datei ca. 800 zu entfernende Einträge hat

 

Das ist ja nahezu eine gesamte Installation... Klingt so, als wenn Du von Testing auf Stable umsteigen willst und dazu temporär die exakten Versionen eingetragen hast, womöglich sogar maschinell. In dem Fall ist wohl portpeek das richtige Tool für Dich.

eix-test-obsolete ist eher für den Fall gedacht, dass Du eine handgepflegte Datei hast, möglicherweise sogar mit Kommentaren, warum welches Paket darin steht.

----------

## Marlo

++

Danke an euch. hatte ich total vergessen.  :Rolling Eyes: 

Grüße

Ma

----------

## mastacloak

 *Finswimmer wrote:*   

> Hm. Und wie kann ich die gefundenen Änderungen dann in die Dateien schreiben lassen?

 

Vielleicht ist enalyze aus gentoolkit einen Versuch wert. Es kann auch /etc/portage/package.*-Dateien regenerieren.

----------

## Jean-Paul

 *mastacloak wrote:*   

> Vielleicht ist enalyze aus gentoolkit einen Versuch wert.

 Danke für den Tip, das Tool kannte ich nicht. 

Hab's auch gleich ausprobiert und es scheint zu funktionieren. 

Und zwar habe ich  *Quote:*   

> x11-drivers/xf86-video-intel ~amd64

  in die keywords eingetragen. Ich habe 2.99.917 installiert, was bis vor kurzem unstable war. Der Eintrag ist also überflüßig und wurde tatsächlich entfernt.

Das Tool hat allerdings auch einen Eintrag hinzugefügt der nicht drin war und auch nicht nötig ist.  *Quote:*   

> media-libs/vo-aacenc ~amd64

 

Gut ist auch, dass enalyze keine "scharfen" Files überschreibt, sondern ein File in home/<user> ablegt.

----------

## Josef.95

Ja, den enalyze Tipp gab es ein paar Beiträge weiter oben auch schon mal  :Wink: 

----------

## ChrisJumper

Och ja Frühjahresputz könnte ich noch auch mal halten. Bei mir ist in der letzten Zeit immer mehr Unstable in die keywords Dateien gerutscht. Zum einen halt der komplette Gnome-3 Desktop. Daneben natürlich diverse Desktop-Programme wie firefox und chromium, bei libre-office nutze ich noch den stable. Flash war mal drin, ist aber mittlerweile draußen seit dem ich das nicht mehr brauche.

Dann habe ich aber noch die kompletten ruby und rails Anwendungen drin.

Aber ich muss auch sagen das ich in letzter Zeit mehr per Hand update. Besonders nach shell-shock hab ich diese auch auf Unstable. Ich überprüfe fast tätlich die Ticker auf Sicherheits-Updates und halt bei Gentoo auch täglich "glsa-check -p $(glsa-check -t all)". Den aktuellen Tree ziehe ich dann aber nur ein mal in der Woche und dann schaue ich auch immer wie viel Compiler-Zeit ich mir antun möchten. Denn auch wenn ich Unstable-Pakete drin habe, werde ich nicht blind Updaten wenn es keine Sicherheits-Hinweise gibt und updates halt mit und mit aktualisieren.

Um bei manchen Paketen dem Unstable-Sog zu entkommen tausche ich halt pauschal unstable gegen ein =dev-libs/pakete-$AKTUELLE_VERSION aus.

Größere Probleme hatte ich hetzt schon länger nicht mehr.

----------

