/albert n00b
![n00b n00b](/images/ranks/rank_rect_0.gif)
![](images/avatars/20300163944d9ff1cecf4a.jpg)
Joined: 17 Jan 2005 Posts: 58
|
Posted: Thu Jul 13, 2006 4:02 pm Post subject: add_keywords.sh und emerge_force.sh und über Portage |
|
|
Hi
Ich denke diese 2 kleinen Skriptchen könnten für einige Gentoo User interessant sein:
http://www.az2000.de/projects/gentoo_helpers
add_keywords.sh erweitert automatisch die package.keywords für ein bestimmtes Paket, welches man in der testing-Version haben will.
emerge_force.sh bricht bei einer längeren Programmliste (z.B. bei einem Systemupdate) nicht ab, wenn ein Fehler aufgetreten ist, sondern kompiliert trotzdem den Rest noch, soweit das möglich ist.
Genauere Beschreibungen auf der oben angegebenen Seite.
Ich denke, zumindest die Funktion des 2. Skriptes könnte man eigentlich auch gut direkt in emerge einbauen. Wenn dies also ein Gentoo Entwickler liest, dann zieht das mal in Erwägung.
Überhaupt finde ich, dass in letzter Zeit immer häufiger Probleme auftreten und selten bei einer längeren Liste von Updates alles fehlerfrei durchläuft. Das ist in jedem Fall auch unabhängig vom System, da ich etwa 5 Gentoo Maschienen (inklusive 3 weitere von Kollegen, die ich zu Gentoo geführt habe, den ich in letzter Zeit bei der Installation immer mal wieder helfen muss, die leider nicht so reibungslos läuft, wie das bei meiner ersten Gentoo-Installation vor 1,5 Jahren war) hier habe und die teilweise noch ganz frisch installiert sind. Das wirft kein gutes Licht auf Gentoo. Früher hab ich immer behauptet, man müsse lediglich einen emerge startet und alles läuft glatt und das stimte auch in 99% aller Emerges früher. Jetzt sind es vielleicht nur noch so etwa 90% bei den Systemprogrammen und vielleicht so 80% bei Anwenderprogrammen.
Ich denke, bei vielen Sachen können die Gentoo Entwickler (bzw. die Portage Releaser) nicht so viel für, wenn die Entwickler der Software diese nicht ganz so sauber programmieren.
Was ihr Gentoo Entwickler allerdings doch tun könntet ist ein besseres automatisches Handling von Fehlern. Bisher ist das gar nicht vorhanden.
Was ich meine sind so Fehler, die recht selbsterklärend sind, wo man bisher aber noch selbsteingreifen muss.
Mal ein paar Beispiele der letzten Zeit:
Eine neue Version von Perl wird installiert. Es wird zwar netterweise am Ende drauf hingewiesen, dass ich evtl. perl-cleaner aufrufen sollte, aber in der Regel würde ich von dieser Meldung nichts mitbekommen, wenn ich mein Update automatisch durchlaufen lasse (und das ist meistens so). Ich fände es toll, wenn ich in der make.conf z.B. so eine Variable "AUTOCLEANER=1" oder so setzen könnte, die nach Updates wie bei Perl oder auch Python (dort entsprechend das Programm python-updater) die entsprechenden Programme automatisch mal durchlaufen lässt. Alternativ dazu, denn es ist ja so eine Frage, ob man das wirklich will, treten manche sehr typischen Fehler auf, wenn man z.B. perl-cleaner nicht aufgerufen hat, obwohl es nötig war. Z.B. habe ich auf mehreren Plattformen immer wieder den Fehler "XML::Parser missing" oder so ähnlich gesehen. Auf solche Fehler sollte emerge automatisch reagieren können, was nicht so schwer zu implemtieren sein sollte. Es gibt eine ganze Reihe von Fehlern, wo ziemlich eindeutig ist, was getan werden muss. Man könnte solche Fehler sammeln und entsprechend automatisch darauf reagieren lassen. Natürlich wird man so eine Liste nie wirklich vollständig haben können, aber zumindest einige viele immer wieder auftretende völlig banale Fehler könnte man so aus der Welt schaffen. In sehr vielen Fällen hilft es prinzipiell, ein Reemerge des angemeckerten Programms durchzuführen.
Auch in anderen Bereichen ist es ähnlich. emerge könnte beispielsweise prinzipiell alle Konfigurationsdateien, die ich niemals selbst geändert habe, automatisch updaten. Dies würde häufiger die Funktionalität des Systems gewähren als andersrum.
Auch mit den Blocks ist das so eine Sache. In manchen Fällen ist absolut klar, was getan werden muss (z.B. die Sache mit dem Pam-Login und Shadow; hier hätte man das ruhig automatisieren können; vielleicht zu Sicherheit noch irgendwie die /bin/login nicht löschen lassen beim entfernen von Pam-Login, falls wirklich etwas schiefgeht). Selbst wenn das nicht so klar ist und nicht so gut eine Reakation automatisiert werden kann für manche Blocks, könnte emerge zumindest doch den anderen Kram emergen, der unabhängig von dem Block ist.
Dies waren erstmal ein paar Anregungen. Wenn nicht grundsätzlich solche Ideen abgelehnt werden (a la "sowas lässt sich sowieso nicht vernünftig lösen, deshalb versuchen wir es gar nicht erst"), werde ich einiges dazu gerne noch weiter vertiefen bzw. an manchen Realisierungen von Lösungen der Probleme wäre ich auch selbst interessiert mitzuarbeiten.
Mfg
Albert |
|