# ~testing -> stable Kriterien/Richtlinien?

## andi_s

Hallo,

ich habe erfolglos versucht irgendwo eine Info darueber zu finden nach welchen Kriterien bei Gentoo die Packages von ~testing auf stable gesetzt werden.

Wie wird das hier mit ~testing -> stable gehandhabt, d.h. wer entscheidet das und nach welchen Kriterien/Richtlinien wird entschieden?

Danke

----------

## franzf

Naja, ausgiebig getestet sollte es sein, heißt ausreichend lange im Portage verfügbar sein (>1 Monat).

Keine neuen Bugs im Bugzilla über gewissen Zeitraum.

Security Fixes gehen schnell(er) stable.

Und natürlich ausreichendes "Interesse" bei den Maintainern  :Very Happy: 

----------

## Max Steel

Oft sind die testingReleases bereits vom Releaser als stable gekennzeichnet und sitzen diese Zeit >1Monat nurnoch aus.

----------

## jodel

ich finde die stable Politik von Gentoo eigentlich gar nicht so schlecht, da ich aber auf meinem Zweitrechner Arch Linux verwende (auch eine Rolling Release Distro) fallen mir da doch ein paar Unterschiede auf, ohne dass ich die unbedingt bewerten will:

- bei Arch ist Chromium schon seit Ewigkeiten im Stable, bei Gentoo nicht.

- bei Arch ist seit gestern Kernel 2.6.33 stable, bei Gentoo haben wir noch 2.6.31 

- lighttpd hat mit 1.4.26 einen wichtigen Security Bugfix bekommen, ist aber immer noch nicht stable in gentoo.

----------

## franzf

 *jodel wrote:*   

> - lighttpd hat mit 1.4.26 einen wichtigen Security Bugfix bekommen, ist aber immer noch nicht stable in gentoo.

 

Das stimmt so aber nicht! Laut ChangeLog hat 1.4.25-r1 diesen Security-Fix bekommen, gleich am 1. Februar.

Und mittlerweile ist auch 1.4.26 stable.

----------

## jodel

 *franzf wrote:*   

>  *jodel wrote:*   - lighttpd hat mit 1.4.26 einen wichtigen Security Bugfix bekommen, ist aber immer noch nicht stable in gentoo. 
> 
> Das stimmt so aber nicht! Laut ChangeLog hat 1.4.25-r1 diesen Security-Fix bekommen, gleich am 1. Februar.
> 
> Und mittlerweile ist auch 1.4.26 stable.

 

wegen des bugfix hast du recht, da war ich falsch informiert, aber 1.4.26 ist nur im x86 stable, bei mir läuft amd64.

insgesamt finde ich die stable politik von gentoo auch total in Ordnung, alles im stable verdient seinen Namen auch zurecht.

Manchmal hätte ich halt nur gerne die gewohnte Stabilität und zugleich die neuen Features, die ein neuer Kernel bringt, wie z.B. die TRIM Unterstützung für SSDs im 2.6.33er, aber beides geht halt schlecht  :Smile: 

----------

## andi_s

Also gibt es keine konkreten Richtlinien, sondern die Maintainer machen das nach Gefühl und Zeit, wenn ich das richtig verstanden habe?

Allerdings wundert es mich das z.B. mozilla-firefox-stable (sicher ein Programm das 80% der User hier taeglich nutzen) noch immer bei Version 3.5.8 rumduempelt. (3.5.8 wurde am 17.2.10 released und 3.6 am 21.1.10.)

Bei dem Sprung von 3.5.x auf 3.6.x moegen neue Abhaengigkeiten die Sache zwar verzoegern, aber nun sind ja fast 3 Monate vergangen - das kommt mir doch schon recht langsam vor. Vor allem Minor-Versionsspruenge (3.6.0 auf 3.6.3 etc.) sollten doch eigentlich keine langen Testphasen mehr benoetigen, da es sich ja nur um Bugfixes handelt.

Beim Kernel kommt mir das aehnlich traege vor oder taeusche ich mich da, wenn ich das Gefuehl habe das Gentoo bei einigen Sachen inzwischen etwas hinter anderen Distributionen hinterherhinkt?

ps: Klar hindert einen Niemand daran einzelne Programme auf ~testing umzustellen, wenn es einem zu langsam geht, aber wenn man damit anfaengt kann man imho wegen der vielen Abhaengigkeiten gleich das ganze System auf ~testing umstellen. Mir ist auch bewusst das hier Freiwillige am Werk sind, also bitte nicht falsch verstehen.

----------

## franzf

 *andi_s wrote:*   

> Vor allem Minor-Versionsspruenge (3.6.0 auf 3.6.3 etc.) sollten doch eigentlich keine langen Testphasen mehr benoetigen, da es sich ja nur um Bugfixes handelt.

 

Aber der Sprung 3.5->3.6 hat gewaltige Änderungen mitgebracht. Ein ".0"-Release hat meistens noch gröbere Schnitzer. Da dauert es etwas, bis man das als "stable" (von mir aus im Gentoo-Sinne  :Wink: ) nennen kann. Du wirst in den nächsten Wochen einen stabilen 3.6er-Firefox bekommen, da bin ich mir sicher.

Schau auch mal nach lde4. Offizielle Aussage: "kde-4.4.2 ist der früheste Kandidat für ein stable kde-4.4".

 *Quote:*   

> Beim Kernel kommt mir das aehnlich traege vor oder taeusche ich mich da

 

Auch hier: Der .33er ist recht neu, da warten die Gentoo-Leute auf die ersten Offiziellen Linux-Patches, bevor da was stabilisiert wird. Vor allem ist ja 2.6.31 und 2.6.32 nicht tot, sondern wird fleißig weiter gepatched. Für Systeme die Rock-Stable laufen müssen, ist ein komplett getesteter Kernel essentiell.

----------

## andi_s

Ja, ist ja alles richtig...

.0er-Releases sind in der Tat meistens Betaversionen, wo der User testen darf - das war schon immer so - auch unter Windows sollte man davon die Finger lassen...  :Wink: 

Ich denke nur das man in dem Moment wo FF 3.6.0 stable ist man eigentlich auch 3.6.3 relativ schnell freigeben koennte, da sich da ja i.d.R. kaum was aendert. Wenn man da auch die >1 Monat warten/testen Politik faehrt verliert man doch immer mehr an Boden zu z.B. Arch. Und FF ist imho eine Anwendung, die man immer auf neustem Stand halten sollte selbst wenn Sie nicht 100% stable ist. Daher habe ich mich halt gefragt ob es nicht sinnvoll waere gewisse 'stable'-Kriterien einzufuehren. Was ist schlimmer: Eine neue FF-Version, die vielleicht mal abstuerzt oder eine veraltete Version, fuer die diverse Exploits im Internet rumgeistern?

Was den Kernel angeht, da kann ich die Zurueckhaltung eher verstehen - der sollte schon richtig stabil sein, wobei .32 ja auch schon eine Weile draussen ist, allerdings kann ich das nicht wirklich beurteilen. Ich weiss nur das Arch nun schon bei .33 'stable' ist und da fragt man sich schon wieso Gentoo nicht wenigstens bei .32 ist.

Ich habe mal irgendwo gelesen das eine der staerken von portage sein soll, das man packages leichter wieder zuruecknehmen kann, wenn Sie Probleme verursachen. Warum nutzt man das nicht, indem man sowas wie Stabilitaetsklassen/Prioritaeten einfuehrt, d.h. bei manchen packages Aktualitaet vor Stabilitaet setzt? Falls es Probleme gibt koennte man die Pakete dann immernoch zurueckziehen. Das kann man zwar auch selbst indirekt ueber ~testing realisieren, aber wenn das zentral gemanaged werden wuerde faende ich das nicht schlecht.

Vielleicht bin ich auch nur zu ungeduldig, aber ich denke schon darueber nach mir mal Arch anzusehen, da Gentoo inzwischen immer mehr hinterherhinkt. Frueher war Gentoo sicher mit die aktuelleste Distribution, allerdings musste ich damals auch schmerzhaft erfahren was schlecht getestete Pakete anrichten koennen. Inzwischen gibt es kaum noch Probleme beim emergen - das ist sicher eine positive Entwicklung, aber irgendwie fehlt mir die richtige Balance zwischen Aktualitaet und Stabilitaet - ich denke da koennte man noch was verbessern oder empfinde nur ich das so?

----------

## franzf

Security Fixes finden  im 3.5er Firefox aber schon noch statt. Oder wundert es dich nicht dass 3.6.0 im Januar erschienen ist, im Februar aber dann ein Update für 3.5 rauskam? Außerdem wird 3.6.0 NIE ein stable-firefox-Kandidat sein. Das ebuild ist ja schon längst nicht mehr verfügbar.

Im Übrigen findest du Bei Gentoo Security Fixes oft in Form von Patches und einer neuen Revision. Das fixed dann NUR das Sicherheitsloch, bringt aber keine neuen Unwägbarkeiten eines kompletten Versions-Upgrades mit an Bord.

Wenn du immer aktuell sein willst, solltest du überlegen, mal ACCEPT_KEYWORDS="~<mein_arch>" zu setzen. Das erspart dir das unkeyworden von Testing-Paketen, du wirst genau so aktuell sein wie bei Arch.

----------

## cryptosteve

Ich finde die Stabilisierungskriterien von Gentoo durchaus gelungen. Vor allem, wenn ich im IRC oder in den Foren berichte über massive Probleme beim emergen sehe, dann stelle ich fest, dass ich die hier in der Form unter stable nicht habe. 

Entweder hab ich ein merkwürdiges System, nur Glück, oder der Stabilisierungsprozess hat ganz eindeutig seine Berechtigung.  :Smile: 

----------

## Josef.95

 *Quote:*   

> Vielleicht bin ich auch nur zu ungeduldig, aber ich denke schon darueber nach mir mal Arch anzusehen, da Gentoo inzwischen immer mehr hinterherhinkt.

 verstehe ich nicht, und kann ich auch nicht nachvollziehen..

all das was du suchst findest du im Testing-Zweig   :Wink: 

Beispiel:

Amarok-2.3 Released am 15.03.2010

http://amarok.kde.org/en/releases/2.3.0

ebuild erstellt und verfügbar am

amarok-2.3.0.ebuild,v 1.1 2010/03/15 12:32:41

Ähnliches bei den kde Releases

da sind die meisten ebuilds schon verfügbar bevor kde überhaupt die Sources raus tut....

bzw bevor das Release erschienen ist.

Also wer will kann sein gentoo via ebuild nahezu brand-Aktuell haben,

man muss es nur nutzen...

Nutze hier seit ca. zweieinhalb Jahren komplett Testing, und komme da idR bestens mit klar.

----------

## Klaus Meier

 *Steve` wrote:*   

> Ich finde die Stabilisierungskriterien von Gentoo durchaus gelungen. Vor allem, wenn ich im IRC oder in den Foren berichte über massive Probleme beim emergen sehe, dann stelle ich fest, dass ich die hier in der Form unter stable nicht habe. 
> 
> Entweder hab ich ein merkwürdiges System, nur Glück, oder der Stabilisierungsprozess hat ganz eindeutig seine Berechtigung. 

 Und ich freue mich, wenn ich mal wieder Probleme habe, ich bin halt Bastler und Pfriemler. Ich arbeite halt im Support und hab es immer gerne, wenn ich Probleme erst mal bei mir habe. Dann weiß man beim Kunden sofort, was man tun muss. Auch wenn es sich da meistens um Windows handelt. Und irgendwer muss die Fehler ja finden...

Aber zum Vergleich Arch/Gentoo. Eine Software wird nicht dadurch stabil, weil man sie aus Testing ins Stable schiebt. Der aktuelle kernel 2.6.33.2 ist unter Gentoo genauso stabil oder instabil wie unter Arch. Es kann ja sein, dass man unter Arch ein besseres Gefühl damit hat als unter Gentoo wegen der Bezeichnung, es ist in beiden fällen der gleiche Kernel. Und das schöne an Gentoo ist da die Flexibilität. Wenn du der Meinung bist, der 2.6.31 ist mir dann doch zu alt und der 2.6.33 noch zu neu, dann nimmst halt den 2.6.32.

Ansonsten gibt es wenig Fälle, wo Software aus Testing echte Probleme macht. In der überwiegenden Zahl der Fälle ist es der Build Prozess, wo es klemmt. Aber wenn die Kiste keine 5 Minuten ausfallen darf, dann ist auch das schon zu viel.

Das einzige, wo Gentoo etwas lahm ist, das ist Gnome. Das dauert immer ein klein wenig lange, bis es dann mal im Testing ist, dafür ist KDE oft schon einen Tag vor dem offiziellen Release drin aber bis zur Freigabe noch hardmasked.

Die Maintainer bei Gentoo sind nicht langsamer als die von Arch, es ist einfach eine andere Sache, die in diesen Fällen halt die gleiche Bezeichnung hat.

----------

## schachti

 *andi_s wrote:*   

> Vielleicht bin ich auch nur zu ungeduldig, aber ich denke schon darueber nach mir mal Arch anzusehen, da Gentoo inzwischen immer mehr hinterherhinkt.

 

Ich habe seit inzwischen relativ langer Zeit alle meine Systeme auf testing umgestellt und bisher keine größeren Probleme gehabt als mit stable-Systemen, gefühlt eher noch weniger. Wenn Dir also Aktualität so wichtig ist, stell doch einfach um.

----------

## cryptosteve

 *Klaus Meier wrote:*   

> Das einzige, wo Gentoo etwas lahm ist, das ist Gnome.

 

Da hab ich aber Glück, dass ich kde-User bin.  :Smile: 

 *Klaus Meier wrote:*   

> Die Maintainer bei Gentoo sind nicht langsamer als die von Arch, es ist einfach eine andere Sache, die in diesen Fällen halt die gleiche Bezeichnung hat.

 

Langsam sind die Maintainer definitiv nicht. Und man darf auch nicht vergessen, dass der Portagetree deutlich mehr Programme umfasst, als es die Arch-Repositories tun. Und AUR als Teil der Archlinux-Struktur ist mit dem Inhalt von Portage nicht gleichzusetzen.

----------

## andi_s

Das ist doch genau der Punkt... es gibt keine eindeutigen Richtlinien, ab wann man packages als stable bezeichnen kann. Daher sind bei gentoo packages in testing, die bei arch stable sind, obwohl es die gleiche Software ist...

Daher finde ich die Wahl zwischen 0 (testing) und 1 (stable) nicht unbedingt optimal. Ein System wo man die Balance systemweit irgendwo zwischen 0 und 1 austarieren koennte faende ich wesentlich sinnvoller. Eine Moeglichkeit waere z.B. so vorzugehen:

- Die Maintainer passen den Stabilitätsgrad des jeweiligen Packages dynamisch der Entwicklung an, d.h. Sie weisen dem package bei Neuerungen immer einen Wert zwischen 0% und 100% zu, wobei 0%==testing entspricht und 100%==stable (diese Werte sind natürlich auch gefühlte Werte und basieren nur auf der Meinung/Erfahrung des Maintainers)

- Der User koennte dann in der make.conf zwei Werte (fuer system & world) zwischen 0% und 100% definieren. Ich wuerde da z.B. fuer system=80% und world=60% waehlen, da ich auf ein rel. stabiles System Wert lege, aber bei Anwendungen aktuellere Versionen bevorzuge und bereit bin Probleme in Kauf zu nehmen.

- den Rest uebernimmt portage und merged nur packages die >= dem definierten Stabilitaetsgrad sind.

So koennte man viel flexibler definieren, worauf man Wert legt. system=80% wuerde dann bedeuten das man packages bekommt, die im Prinzip stabil sind, aber eben noch nicht als stable freigegeben wurden, weil der Maintainer vielleicht noch >1 Monat abwarten will.

Ein schoener Nebeneffekt waere das man so den aktuellen Stand der Dinge auf packages.gentoo.org verfolgen koennte (package ist bei 70% etc.) und man auch eine Datenbasis erhalten wuerde, die man auswerten koennte. D.h. man koennte anhand von Statistiken festellen ob die maintainer zu vorsichtig sind oder eben zu voreilig und dann seine make.conf entsprechend justieren...

Vielleicht liest das hier ja einer der Entwickler und denkt mal darueber nach - ist 'im Prinzip' ja relativ simpel und wuerde noch mehr Flexibilitaet bringen und das ist ja genau das was die Meisten an Gentoo moegen...  :Wink: 

----------

## franzf

Solche Diskussionen gab es schon öfters.

Um es kurz zu machen:

Gentoo (und definitiv arch ebenso) würde die Manpower fehlen, so ein System durchzuziehen. Es gibt sinnvollere Felder auf die ein Dev Wert legen sollte.

Selbst eine einzige zusätzliche Stufe "nearly stable"  zwischen stable und testing wäre vom Aufwand her nicht zu bewältigen. Denn wie willst du es mit den Abhängigkeiten machen?

kde-4.4 braucht gewisse Mindestanforderungen. kde-4.4.2 ist mittlerweise ziemlich stabil, läuft hier absolut rund. stable KANN man es nocht nicht bezeichnen. Jetzt existiert Abhängigkeit XYZ, die nur "testing" ist. Der Maintainer von XYZ sagt "es ist nicht sinnvoll XYZ schon als nearly stable zu bezeichnen". Was macht der kde-Maintainer jetzt bitte?!?

Oder aktuelles Beispiel: Dolphin hat nen Memory Leak in den thumnailers (glaub mplayerthumbs war das). Das heißt das Ding kann definitiv noch nicht nach nearly stable gehen. kdelibs sind aber definitv nearly stable-zauglich. Jetzt gibt es natürlich noch mehr Anwendungen als nur dolphin, die kdelibs brauchen. Z.B. konsole. Und die sind wiederum sehr wohl nearly stable-tauglich. Wenn man jetzt sagt "kdelibs + konsole -> nearly stable; dolphin -> testing" bekommt man einen richtig schön unüberschaubaren Wust.

-> unmaintainable, bei der Manpower die Gentoo hat.

----------

## Necoro

Außerdem: Wenn es schon an genauen Spezifikationen fehlt, ob ein Paket bei 0 (testing) oder 1 (stable) ist -- wie willst du denn die Prozentzahlen in der Mitte angeben? Das wird doch denn ein kruder Mischmasch aus den Bauchgefühlen der Maintainer ...

Und was machst du, wenn ein paket bei ... 0.8 steht und ein böser Bug auftaucht. Soll das denn zurückgestuft werden? Und du denn immer mit up- und downgraden beschäftigt sein?

----------

## Klaus Meier

 *andi_s wrote:*   

> Das ist doch genau der Punkt... es gibt keine eindeutigen Richtlinien, ab wann man packages als stable bezeichnen kann. Daher sind bei gentoo packages in testing, die bei arch stable sind, obwohl es die gleiche Software ist...
> 
> Daher finde ich die Wahl zwischen 0 (testing) und 1 (stable) nicht unbedingt optimal. Ein System wo man die Balance systemweit irgendwo zwischen 0 und 1 austarieren koennte faende ich wesentlich sinnvoller. Eine Moeglichkeit waere z.B. so vorzugehen:

 Es hindert dich doch keiner daran, dies manuell zu tun. Genau das hatte ich doch geschrieben. Wenn dir 2.6.31 zu alt und der 2.6.33 zu neu ist, dann nimm doch einfach den 2.6.32. Du kannst doch jedes Paket mit emerge =xyz in einer ganz bestimmten Version installieren. Beim Firefox ist es halt so, wenn man ihn ausschließlich zum Browsen nutzt, ist es nicht so schlimm, wenn er mal abstürzt. Was die ersten Versionen des 3.5 bei mir recht häufig getan haben. Dafür hast du dann mit den neuesten Versionen die höchste Sicherheit. Alternativ, wenn du Firefox nutzt, um lokal bestimmte Anwendungen laufen zu lassen, dann kann dir die Sicherheit egal sein, aber das Teil sollte nicht abstürzen.

Ansonsten gibt es bald zwischen 0 und 1 so viele Zwischenstufen wie es Gentoo Nutzer gibt. Weil dann jeder gerne eine Stufe hätte, die genau seinen Wünschen entspricht. Oder anders formuliert. Wer es allen Recht machen will, der macht es keinem Recht. Es ist einfacher und schneller, das von Paket zu Paket zu entscheiden, als dafür einen komplexen Regelsatz zu erstellen.

Ansonsten ist Arch doch relativ identisch mit Gentoo Testing. Das ist es auch, wozu ich dir raten würde. Du musst keine Angst haben, dass dir dein System alle paar Minuten abstürzt. Es ist Testing, nicht Unstable, auch wenn es von einigen so bezeichnet wird. Unstable würdest du bekommen, wenn du dir die Overlays freischaltest.

----------

## Josef.95

 *Quote:*   

> Unstable würdest du bekommen, wenn du dir die Overlays freischaltest.

  das ist vermutlich etwas unglücklich formuliert.., Overlays kann ja alles Mögliche sein..

Unstable Pakete würde ich eher dort vermuten die mit package.unmask freigeschaltet werden, sprich hart maskierte Pakete.

/edit: siehe zb auch: http://www.gentoo.org/doc/de/handbook/handbook-ppc.xml?part=3&chap=3Last edited by Josef.95 on Sun Apr 11, 2010 11:55 am; edited 1 time in total

----------

## Necoro

 *Josef.95 wrote:*   

>  *Quote:*   Unstable würdest du bekommen, wenn du dir die Overlays freischaltest.  das ist vermutlich etwas unglücklich formuliert.., Overlays kann ja alles Mögliche sein..
> 
> Unstable Pakete würde ich eher dort vermuten die mit package.unmask freigeschaltet werden, sprich hart maskierte Pakete.

 

Wobei Pakete in Overlays eher selten hart maskiert sind ... auch wenn sie nicht so recht laufen ...

Aber ich denke, Overlays wie "sunrise" oder so sind auch qualitativ nicht schlecht und recht stabil (wobei das ja denn doch schon Ähnlichkeit zum AUR hat  :Very Happy: )

----------

## Josef.95

@Necoro

Ein klein wenig kann man sich da ja auch zb nach den farbigen Sternchen in der "layman -L" Liste orientieren (rot gelb grün)

da gibt es doch enorme Unterschiede,

aber hast schon recht, es gibt da durchaus auch sehr gut und sauber geführte Overlays (zb auch "kde")

----------

## cryptosteve

 *schachti wrote:*   

> Ich habe seit inzwischen relativ langer Zeit alle meine Systeme auf testing umgestellt und bisher keine größeren Probleme gehabt als mit stable-Systemen, gefühlt eher noch weniger.

 

Hier würde ich gerne nochmal nachhaken. Was meinst Du hier mit "bisher keine größeren Probleme, [ ... ] gefühlt eher noch weniger"? Reden wir hier von Problemen mit den Programmen an sich, oder (auch) mit gefühlt weniger Problemen bei der Nutzung von emerge (blocks, Compile-Abbrüche, etc.)?

----------

## Klaus Meier

Ok, nicht jedes Overlay ist unstable, aber wer unstable will, der kommt an den Overlays nicht vorbei....

Die package.mask wird aktuell dafür nicht mehr sehr oft genutzt.

----------

## schachti

 *Steve` wrote:*   

> Was meinst Du hier mit "bisher keine größeren Probleme, [ ... ] gefühlt eher noch weniger"? Reden wir hier von Problemen mit den Programmen an sich, oder (auch) mit gefühlt weniger Problemen bei der Nutzung von emerge (blocks, Compile-Abbrüche, etc.)?

 

Sowohl als auch. Bei der Nutzung der Software habe ich gar keinen Unterschied gemerkt (wobei ich auch nur maximal ein paar Dutzend Programme zumindest so oft benutze, dass ich das beurteilen kann), beim emerge passiert es ab und an mal, dass ein Paket sich nicht installieren lässt - dann findet sich entweder auf bugs.gentoo.org relativ schnell ein Fix, oder man probiert es ein paar Tage später nochmal (aber das passiert, wie gesagt, nur ab und an - ich mache manchmal täglich, manchmal alle 2-3 Tage ein Update, und sowas kommt grob geschätzt 1 x pro Monat vor).

----------

## cryptosteve

Klingt ja bedeutend weniger dramatisch als es z.B. bei der Benutzung von Debian sid ist - auch dort lösen sich die meisten Probleme, wenn man das Upgrade ein paar Tage später einfach nochmal versucht.

Am schlimmsten stelle ich mir dabei 'blocks' vor.

----------

## Klaus Meier

An die einzigen Probleme, an die ich mich erinnern kann, sind dolphin, der irgendwann mal recht häufig abgestürzt ist. Das ist bei 4.4.2 behoben. Speicherleck beim kio_thumbnailer, keine Ahnung, ob schon behoben, lässt sich mit 2 Klicks durch Änderung des Backends beheben und der schon erwähnte Firefox 3.5 ganz am Anfang. Sind die einzigen Probleme, an die ich mich so aus dem letzten Jahr erinnere.

Blocks sind gar kein Problem. Lassen sich dadurch beheben, in dem man das Paket, welches blockt einfach deinstalliert. Und wenn ein Update nicht durchläuft, was vielleicht einmal im Monat vorkommt, ist doch nicht so schlimm, du hast ja ein System. Und das Problem löst sich normalerweise innerhalb von 24 Stunden ohne weiteres Zutun. Ich nutze Testing, solange ich bei Gentoo bin. Und konnte es immer nutzen.

----------

## cryptosteve

Hmm ... klingt ja durchaus interessant. 

Ist 

```
ACCEPT_KEYWORDS="~$arch"
```

in /etc/make.conf (noch) der richtige Weg dafür?

----------

## Klaus Meier

Ja, so ist es. Was du unbedingt beachten solltest ist folgendes: http://www.gentoo.org/doc/de/openrc-migration.xml

Denn du bekommst durch das Update baselayout2. Das sollte eigentlich automatisch angepasst werden, aber überprüfe das alles noch mal, sonst hast du Pech und der Rechner startet erst gar nicht.

Ansonsten gut beachten, was so in den Elogs steht, da gibt es eventuell noch etwas Nacharbeit. Und ich würde dann erst mal mit emerge -uDN system anfangen, danach xorg-x11 usw. Dann hast du nicht alles auf einmal. Und wenn etwas nicht läuft, revdep-rebuild ist dein Freund. Das wirst du benötigen.

----------

## Josef.95

@Steve`

wenn du es nun tatsächlich umstellen möchtest, lege dir besser vorher ein komplettes System-Backup an!

Beachte, ein zurück zu stable ist nicht so ohne weiteres möglich!

----------

## nikaya

... und wenn ich mir hier einige Posts bezüglich Problemen beim Update kde-4.3 --> kde-4.4 anschaue evtl. kde-4.3 vorher komplett entfernen. Und evtl. noch Ordner ~/.kde4 vorher sichern und entfernen.

----------

## Josef.95

 *nikaya wrote:*   

> [....] Und evtl. noch Ordner ~/.kde4 vorher sichern und entfernen.

  Das sollte idR eigentlich nicht nötig sein, doch wenn, dann würde ich auch die Cache-Verzeichnisse unter /var/tmp/kde* mit entfernen.

So startet man dann mit einer gaaanz frischen Session...  :Wink: 

----------

## cryptosteve

Moin,

quasi tagesaktuelle Backups von /home, sowie ausgewähltem Inhalt aus /etc und /var habe ich grundsätzlich. 

Sollte ich den Schritt tatsächlich wagen, würde ich sowieso schwer darüber nachdenken, entweder mit einer frischen Installation zu starten, oder wenigstens vorher die großen Pakete zu entfernen (kde4, Xorg, etc.).

Ein ganz blauäugiger Versuch mit 'pretend' führt nämlich schnell zutage, dass es zwischen KDE4.3 und KDE4.4 jede Menge Blocks gäbe, wenn man nicht mit 'kdeprefix' arbeiten würde.

----------

## Josef.95

 *Steve` wrote:*   

> Moin,
> 
> [....]
> 
> Ein ganz blauäugiger Versuch mit 'pretend' führt nämlich schnell zutage, dass es zwischen KDE4.3 und KDE4.4 jede Menge Blocks gäbe, wenn man nicht mit 'kdeprefix' arbeiten würde.

 Moin!

also von "kdeprefix" würde ich auf alle fälle abraten, da kannst du dich sehr schnell im Teufels Küche manövrieren..

siehe evtl auch hier: https://forums.gentoo.org/viewtopic-t-822572.html

Bei deinen Block vermute ich mal unnötige Einträge in /var/lib/portage/world

Ist evtl. mal was mit Versions-Angabe, etwa "emerge =kde-base/libknotificationitem-4.3.5" ins world file geraten?

Normal, wenn du zb kdebase-meta oder kde-meta usw installiert hattest sollte es da keine Blocks geben.

----------

## disi

 *schachti wrote:*   

>  *Steve` wrote:*   Was meinst Du hier mit "bisher keine größeren Probleme, [ ... ] gefühlt eher noch weniger"? Reden wir hier von Problemen mit den Programmen an sich, oder (auch) mit gefühlt weniger Problemen bei der Nutzung von emerge (blocks, Compile-Abbrüche, etc.)? 
> 
> Sowohl als auch. Bei der Nutzung der Software habe ich gar keinen Unterschied gemerkt (wobei ich auch nur maximal ein paar Dutzend Programme zumindest so oft benutze, dass ich das beurteilen kann), beim emerge passiert es ab und an mal, dass ein Paket sich nicht installieren lässt - dann findet sich entweder auf bugs.gentoo.org relativ schnell ein Fix, oder man probiert es ein paar Tage später nochmal (aber das passiert, wie gesagt, nur ab und an - ich mache manchmal täglich, manchmal alle 2-3 Tage ein Update, und sowas kommt grob geschätzt 1 x pro Monat vor).

 

Genau deswegen heisst das ja "testing"  :Smile: 

Gerade in Gentoo hat ja jeder sein individuelles System und wenig ist Standart. Da muss man dann schonmal etwas warten bis alle es ausgibig getestet haben.

Kleines Beispiel: Der disi aktualisiert seinen Tree und will mozilla-thunderbird installieren. Kann er aber nicht, weil kein alsa installiert wurde. Dabei schreibt das Makefile auch schoen die richtige flag hin, die er braucht damit es funktioniert. Dann filed er einen Bug Report und fragt mal, ob er ein alsa Flag haben darf und bums 2 Tage spaeter kann man das Programm aus dem Portage ohne alsa installieren.

Wo ich stable nehme, will ich nichts testen sondern "nur" die Security-Updates oder vorher ausgibig getestete neue Features. Wie schon erwaehnt kann man das in Gentoo sogar stable/unstable angenehm mixen, so lange es gut geht...

----------

## Klaus Meier

 *Steve` wrote:*   

> Moin,
> 
> quasi tagesaktuelle Backups von /home, sowie ausgewähltem Inhalt aus /etc und /var habe ich grundsätzlich. 
> 
> Sollte ich den Schritt tatsächlich wagen, würde ich sowieso schwer darüber nachdenken, entweder mit einer frischen Installation zu starten, oder wenigstens vorher die großen Pakete zu entfernen (kde4, Xorg, etc.).
> ...

 Ich hoffe, wir haben dir nicht zu viel Angst gemacht. Du bekommst halt alle Aktualisierungen auf einmal, die du sonst in einem halben Jahr hättest. Und da kommt man schnell mal durcheinander.

Ansonsten, eine komplette Neuinstallation ist wirklich der beste Weg, kompilieren musst du sowieso jedes Paket neu, und du hast dann eine saubere Konfiguration, also nicht die Gefahr, dass du vergessen hast, Altlasten zu aktualisieren. Das war eine sehr gute Idee. Hätte ich auch drauf kommen können.... kdeprefix solltest du besser nicht verwenden. Bei den Blocks gibt es das b und das B. Die mit dem b werden automatisch gelöst, die mit dem B nicht. Da machst du einfach emerge -C BlockendesPaket.  Mit emerge -uDN world kommt das fehlende Paket dann sofort wieder.

Ansonsten, es ist kein Wagnis, ich lebe damit seit 2005. Aber es ist auch nicht 100% stressfrei.  Sagen wir so: No risk, no fun. Das ist mein Lebensstil.

----------

## Josef.95

 *Klaus Meier wrote:*   

> [....] Bei den Blocks gibt es das b und das B. Die mit dem b werden automatisch gelöst, die mit dem B nicht. Da machst du einfach emerge -C BlockendesPaket.  Mit emerge -uDN world kommt das fehlende Paket dann sofort wieder.

 Sowas würde ich nicht so pauschal sagen, einfach die Blocker deinstallieren kam auch mächtig nach hinten losgehen (wenn man das falsche Paket deinstalliert) Ich erinnere mich noch an einige Threads wo Leute einfach mal python oder coreutils usw wegen eines Blocks deinstalliert hatten...

Also ein wenig aufpassen muss man da schon, besonders bei den Paketen des System Sets..  :Wink: 

----------

## Klaus Meier

Also bei Python und den Coreutils hatte ich noch nie ein B. Und es gibt bei emerge -C ja zwei Stufen, bei der einen darfst du 5 Sekunden überlegen, ob du es willst, bei der zweiten wird dir 10 Sekunden lang gesagt: Du machst dein System unbrauchbar, willst du das wirklich?

Die letzten Blocks die ich hatte waren die e2fsprogs bei der Installation und Poppler.  Und wenn man etwas bei KDE killt, dann killt man nicht das System. Na klar, wenn du nach einem Update von gcc hinterher emerge -C gcc machst, dann Gnade deiner Asche.... Aber das hat nichts mit Blocks zu tun.

----------

## Josef.95

 *Klaus Meier wrote:*   

> Also bei Python und den Coreutils hatte ich noch nie ein B. Und es gibt bei emerge -C ja zwei Stufen, bei der einen darfst du 5 Sekunden überlegen, ob du es willst, bei der zweiten wird dir 10 Sekunden lang gesagt: Du machst dein System unbrauchbar, willst du das wirklich?
> 
> Die letzten Blocks die ich hatte waren die e2fsprogs bei der Installation und Poppler.  Und wenn man etwas bei KDE killt, dann killt man nicht das System. Na klar, wenn du nach einem Update von gcc hinterher emerge -C gcc machst, dann Gnade deiner Asche.... Aber das hat nichts mit Blocks zu tun.

 nach eine sehr kurzen suche hier im Forum... zb

https://forums.gentoo.org/viewtopic-t-688104-start-0-postdays-0-postorder-asc-highlight-coreutils.html

 :Wink: 

----------

## Klaus Meier

Ich denke, das geht jetzt in eine Richtung, die nichts mehr mit dem Thread zu tun hat. Nicht das du Unrecht hast, aber es geht hier um Blocks, die ein Update von KDE 4.3 auf 4.4 mit sich bringt. Und ich glaube nicht, dass da die Coreutils betroffen sind.

----------

## cryptosteve

Hi,

zunächst einmal danke für den Hinweis bzgl. 'kdeprefix'. Die Thead diesbezüglich hatte ich allerdings schon gelesen und wollte mit meinem Hinweis darauf nicht in gleichem Zuge andeuten, es auch nutzen zu wollen ... abgesehen davon erkenne ich für mich keinen Vorteil darin, kde4.3 und kde4.4 parallel laufen zu lassen.

Ansonsten habe ich reichlich Erfahrungen mit testing/unstable-Systemen wie z.B. FreeBSD-Current und Debian sid. Ich meine auch mich an Zeiten erinnern zu können, in denen ~arch durchaus problematischer war (Ende 2003 bis Anfang 2005), aber das kann möglicherweise auch an meiner geringeren Kenntnis damals gelegen haben.  :Smile: 

Und nein, ihr habt mir keine Angst gemacht und ich habe auch keine Befürchtungen, in einem Anflug von Mut systemimmanente Teile des Systems zu unmergen. Ich mache schon lange genug mit Linux rum, um zu wissen, dass man bestimmte Fragen nicht blind mit 'Ja' bestätigen sollte.  :Smile: 

Bzgl. der Blocks könnte ich jetzt noch einen CODE-Block hier reinhauen, aber ich denke mal, ihr habt wenig Interesse an >400 Zeilen emerge-Output.  :Smile:  Mein world-File ist übrigens frei von Versionseinträgen. Ich würde aber gar nicht groß fackeln und KDE4 gleich wegputzen. 

(falls es trotzdem jemanden interessiert: http://daemon.crashmail.de/~stell/emerge_output_20100412.txt)

----------

## Klaus Meier

Also ich habe da nur b gesehen, kein B. Das geht alles problemlos durch.

----------

## franzf

Dass der emerge nicht will hat aber rein gar nix mit kde zu tun! Die kleinen "b" sind doch eindeutig.

Du hast Probleme mit mysql  :Wink: 

Kann es sein, dass bei dir virtual/mysql-5.1 unmasked ist, dev-db/mysql-5.1 aber nicht? Falls das nicht zutrifft, schau einfach mal in der Ecken weiter.

----------

## Josef.95

@Steve`

Das schaut doch schon recht gut aus, einzig mysql-5.0 wirst du dich drum kümmern müssen.

Ansonsten würde ich noch "boost-build" und "boost" vorher deinstallieren, idR reicht da eine Version.

Viel Erfolg!

----------

## cryptosteve

 *franzf wrote:*   

> Dass der emerge nicht will hat aber rein gar nix mit kde zu tun! Die kleinen "b" sind doch eindeutig.

 

Ich habe wohl bei all den Informationen überlesen, dass die 'selbstauflösend' sind.

 *franzf wrote:*   

> Du hast Probleme mit mysql 
> 
> Kann es sein, dass bei dir virtual/mysql-5.1 unmasked ist, dev-db/mysql-5.1 aber nicht? Falls das nicht zutrifft, schau einfach mal in der Ecken weiter.

 

Nee, mit so Einzelsachen komm ich schon klar. Bzgl. mysql bin ich übrigens nirgendwo von stable abgewichen. 

Am meisten Bauchschmerzen macht mir noch die Sache mit OpenRC, obwohl sich das in der Praxis vermutlich in Wohlgefallen auflösen wird.

Ich ziehe nochmal ein aktuelles Backup und guck dann mal, ob da ohne Neuinstallation was geht. Ansonsten muss ich da am Wochenende mal in aller Ruhe ran.

----------

## Polynomial-C

Zu dem ursprünglichen Thema testing --> stable mal noch Anmerkungen:

Es gibt für uns package maintainer Regeln (Abschnitt "Moving from ~arch to arch"), wie beim Stabilisieren eines Pakets zu verfahren ist. Dort steht zum beispiel auch, daß das eigentlich Stabilisieren von den sog. arch-teams vorgenommen werden muß. Ich als "popliger" Paketverwalter darf nur den Stabilisierungsprozess mittels bug request anstoßen. Kommen dann noch weitere Abhängigkeiten hinzu, die ebenfalls stabilisiert werden müssen, und betrachten wir uns zusätzlich noch die fehlende manpower mancher arch-teams, kann sich die Stabilisierung von Paketen ganz schön in die Länge ziehen.

Am Beispiel von firefox-3.6.3 dürft ihr euch gerne mal ein Bild machen, wieviele weitere Pakete in den Prozess involviert sind und wie lange der gesamte Stabilisierungsprozess dauert bzw. noch dauern wird.

----------

## nikaya

 *Steve` wrote:*   

> Am meisten Bauchschmerzen macht mir noch die Sache mit OpenRC, obwohl sich das in der Praxis vermutlich in Wohlgefallen auflösen wird.

 

Bei mir lief das völlig ohne Probleme. Ich hatte auch erst etwas Bedenken und habe alles doppelt kontrolliert vor dem Reboot. Es wurde aber alles sauber nach Openrc migriert ohne Notwendigkeit manueller Anpassung.

 *Steve` wrote:*   

> Ich ziehe nochmal ein aktuelles Backup und guck dann mal, ob da ohne Neuinstallation was geht. Ansonsten muss ich da am Wochenende mal in aller Ruhe ran.

 

Wie Du schon selber erwähntest ist eine Neuinstallation wohl die einfachste und sauberste Methode, da sowieso (fast) alles neu gebaut werden muss. Das Grundsystem ist schön schlank und am wenigsten Probleme zu erwarten.

----------

## cryptosteve

 *nikaya wrote:*   

> Bei mir lief das völlig ohne Probleme. Ich hatte auch erst etwas Bedenken und habe alles doppelt kontrolliert vor dem Reboot. Es wurde aber alles sauber nach Openrc migriert ohne Notwendigkeit manueller Anpassung.

 

Ich will hier nicht groß rumnerven, weil's schon arg OT ist (ansonsten müßte ein Moderator den Thread mal bitte zweiteilen), aber um das noch kurz zum Abschluss zu bringen:

Ich habe das Upgrade auf testing gestern nachmittag noch angestoßen. Amarok/mysql hatte ich vorher noch runtergeschmissen und das Upgrade dann mit einem beherzten emerge-Aufruf angestoßen. Im Laufe des Upgrades ist emerge mehrfach abgebrochen (viermal insgesamt). Ich bin diesbezüglich allerdings jedesmal mit etwas Mitdenken bzw. Nachlesen im Bugtracker weitergekommen (emerge -v1 $foobar). Die Migration nach OpenRC hat gut funktioniert. Nach dem Reboot ist mir allerdings sysklogd (klogd) hängen geblieben, sodass ich nicht erfolgreich booten konnte. Nach etwas Recherche hab ich dazu sowohl einen alten Bug gefunden als auch rausbekommen, dass klogd hier segfaulted. Egal, erstmal raus aus dem Default-Runlevel und erfolgreich gebootet. Klappt. Start von Xorg hat dann nicht geklappt, Kernel Mode Setting im Kernel 2.6.33 fehlt -> reinkompiliert, rebootet .. geht immer noch nicht. Fest eingebaut, rebootet, geht immer noch nicht. Ach, grub-config sollte man schon ändern, dann klappt's auch mit dem neuen Kernel. Und siehe da .. startet. 

Im KDE kämpfe ich jetzt noch mit ein paar kleineren Problemen (Fonts anpassen, meine alte conky-Config läßt conky verrecken, etc.). Hat insgesamt aber gut geklappt. Danke für den Zuspruch.

----------

