Mageia Forum

Ich weiß, die Option '--auto-orphans' soll man vorsichtig einsetzen. Da es sich um ein frisch installiertes System handelte, habe ich einfach mal den Befehl eingegeben, ich erwartete ja nicht, dass dadurch auch elle möglichen wichtigen Systemdienste ausfallen könnten! Eine kleine Auswahl: cron daemon, up/down network, Display Manager, postfix, usw.
Am Ende bleibt der Startprozess noch in der "prä-X-Server"-Phase stehen. Das dürfte doch, bei aller Freude an der Eigenverantwortlichkeit des Users, nicht geschehen!

Habe eben nochmal den gleichen Versuch mit Mageia 1 auf dem gleichen Rechner gemacht.
1. Installation mit gleicher Paketauswahl
2. Updates installiert
3. Neu gebootet
4. urpmi --auto-orphans' gestartet. Ebenso wie bei der Alpha2 waren über 100 Orphans vorhanden.
Danach startete das System einwandfrei.

Mit anderen Worten: es ist ein Bug vorhanden, durch den für das System wichtige Pakete als Orphans erkannt werden.

Das orphans-System unterscheidet nicht nach "Wichtigkeit" der Pakete, das kann nicht beurteilt werden.
Sollte aber schon längst verbessert werden, aber die Entwickler (oder der) sind da etwas anderer Meinung.

Kannst du ja mal als Bug melden für Cauldron

Welchen Sinn sollte eine Bugmeldung haben, wenn sich der maßgebliche Entwickler dagegen sperrt? Der würde sich auch gegen die Einführung einer Lösung sperren, wenn es ein anderer macht.
Kannn mir schon denken, wer das ist, es gab ja schon Diskussionen auf irgendeiner ML. Demokratie geht halt nur bis zu einer bestimmten Grenze, auch bei Mageia.

Wie auch immer, verändert werden muss da auf jeden Fall etwas, nicht nur der Wortlaut der orphans-Meldung.
Auch sollte sie definitiv nicht in der grafischen Oberfläche angezeigt werden und verbessert werden. Bei Debian etwa
scheint die purge-Funktion ja gut zu funktionieren und sehr gefragt und oft benutzt zu sein, warum sollte das nicht auch bei urpmi gehen?
Gegen rationale Fakten kann sich niemand langfristig sperren.

Ich wäre momentan dafür, die komplette orphans-Funktionalität einfach zu deaktivieren. Entweder ganz oder gar nicht ...

doktor5000 hat geschrieben:Ich wäre momentan dafür, die komplette orphans-Funktionalität einfach zu deaktivieren. Entweder ganz oder gar nicht ...

Das würde mich zwischen einen Felsen und einen harten Platz klemmen. Die auto-orphans Funktion ist wichtig bei Geräten mit kleinem Massenspeicher. Ich habe eine 4GB SSD, da machen über 100 Pakete mehr oder weniger schon einen Unterschied. Wie gesagt, der Effekt trat bei gleichem Gerät und gleicher Vorgehensweise bei Mageia 1 nicht auf. Demzufolge ist es ein Bug.

Aber wenn das so weitergeht, kommt da sowieso irgendein anderes Leicht-System drauf - wenn ich denn unter einem anderen System den Broadcom 4312 zum Laufen beköme (da wäre antiX genau richtig gewesen).

wobo hat geschrieben:Aber wenn das so weitergeht, kommt da sowieso irgendein anderes Leicht-System drauf - wenn ich denn unter einem anderen System den Broadcom 4312 zum Laufen beköme

Nach meiner Erfahrung mit dem neuen Notebook, könnte *buntu einen Test wert sein.

Mhmm, das ist aber nicht der Zweck der auto-orphans-Funktion, meiner Meinung nach. Nach Installation sollte es eigentlich überhaupt keine verwaisten Pakete geben, auch meiner Meinung nach. Meine Lösung wäre die Minimal-Installation über urpmi in ein chroot, mit Installation von basesystem-minimal unter Zuhilfenahme von --no-suggests.
Siehe dazu evtl. https://wiki.mageia.org/en/Packagers_chroot

doktor5000 hat geschrieben:Mhmm, das ist aber nicht der Zweck der auto-orphans-Funktion, meiner Meinung nach.

Welcher denn ausser dem Entfernen nicht benötigter Pakete mit dem Ziel, den besetzten Platz freizubekommen?

Nach Installation sollte es eigentlich überhaupt keine verwaisten Pakete geben,

Wie Du siehst, ist das trotzdem der Fall. Habe ich auch schon öfter beobachtet.

Meine Lösung wäre die Minimal-Installation über urpmi in ein chroot, mit Installation von basesystem-minimal unter Zuhilfenahme von --no-suggests.
Siehe dazu evtl. https://wiki.mageia.org/en/Packagers_chroot

Und wofür soll das die Lösung sein? Komme da nicht ganz mit.

man-draker hat geschrieben:Nach meiner Erfahrung mit dem neuen Notebook, könnte *buntu einen Test wert sein.

Nee, zu fett. Da könnte ich auch Mageia mit Gnome nehmen. Außerdem läuft mit der Intel 945 laut Aussage des Installationssystems kein Unity (habs schon probiert). Mit der 4312 gibt es ebenso Probleme.
Im Moment ist Mageia 1 mit LXDE drauf, das geht so einigermaßen....

Auf meinem Netbook läuft Cauldron mit LXDE, das geht ganz gut, allerdings habe ich auch ne 160GB-HD und keine 4GB-SSD.

Eine Frage: Hast Du von der Live oder der DVD installiert? Ich kann mich an ein Problem mit der GNOME-Live im Pre-Release-Test erinnern, das war das "base-system-Paket" nicht drauf...

Oliver

obgr_seneca hat geschrieben:Eine Frage: Hast Du von der Live oder der DVD installiert?

Von der DVD.

Was hattest Du mit Minimal-Installation über urpmi in ein chroot, mit Installation von basesystem-minimal unter Zuhilfenahme von --no-suggests. gemeint? Wofür sollte das eine Lösung sein?

Das Problem ist, dass die auto-orphans-funktion nicht offiziell dokumentiert ist, so ist auch ihr Einsatzzweck nicht klar definiert,
außer durch die Wunschvorstellungen der Nutzer. Das einzige was ich gerade dazu finde ist:

man urpmi.files hat geschrieben: /var/lib/rpm/installed-through-deps.list
Contains the name of the packages that were selected indirectly, ie
not requested by user (eg: libxxxN). It is used to detect orphans
(try "urpme --auto-orphans" and see).

The format of the file is: one package name per line, or optionally
"xxx (required by ...)"

Zum zweiten, wie gesagt so sehe ich das, dass es nach einer DVD-Standardinstallation anders aussieht weiß ich auch.

Zum dritten, du könntest per chroot dir deine minimale Minimalinstallation zurechtbasteln, um das Problem mit
dem Entfernen unnötiger und damit Platz verschwendender Pakete zu umgehen, indem diese gar nicht erst installiert werden.
Ersetzt die Minimalinstallation die du mit dem Installer vornimmst. mit etwas händischer Nacharbeit.

Allerdings ist die Erzeugung der initrd auf diese Weise etwas komplex. Ich habe irgendwann mal auf MU.de beschrieben wie man das macht, allerdings wird mittlerweile nicht mehr mkinitrd sondern dracut verwendet, um die initrd zu erzeugen. Entsprechend müsste man das anpassen

Oliver

doktor5000 hat geschrieben:Zum dritten, du könntest per chroot dir deine minimale Minimalinstallation zurechtbasteln, um das Problem mit
dem Entfernen unnötiger und damit Platz verschwendender Pakete zu umgehen, indem diese gar nicht erst installiert werden.
Ersetzt die Minimalinstallation die du mit dem Installer vornimmst. mit etwas händischer Nacharbeit.

Mit anderen Worten: bastel Dir deine eigene ISO aus einem Basissystem. Auf die Idee bin ich auch schon gekommen, aber es gibt weniger aufwändige Lösungen.

Nun ja, nicht die ISO, nur die Installation...

Oliver

obgr_seneca hat geschrieben:Nun ja, nicht die ISO, nur die Installation...

Äh, und wovon soll ich das in chroot erstellte System installieren? (ich meine das in chreoot bearbeitete)

Nun, Du bootest eine Live-CD und partitionierst Deine ssd wie gewünscht und mountest sie.
Dann kannst Du mit

Code: Alles auswählen

urpmi --urpmi-root /Pfad/zur/Zielpartition --no-suggests basesystem

ein minimales Grundsystem installieren.
Lustig wird's dann, Du musst nämlich einen Bootloader schreiben und eine initrd erzeugen :/

Oliver

obgr_seneca hat geschrieben:Lustig wird's dann, Du musst nämlich einen Bootloader schreiben und eine initrd erzeugen :/

Ja. Ich schreib Dir wenn ich das gelernt habe, dann kann ich Deine Idee ja mal ausprobieren.

wobo hat geschrieben:Mit anderen Worten: bastel Dir deine eigene ISO. Auf die Idee bin ich auch schon gekommen, aber es gibt weniger aufwändige Lösungen.

Nicht ISO, sondern fertige Installation, ist schon ein Unterschied.

Eine weniger aufwändige Lösung wäre etwa, alle installierten Pakete mit Größe (und Name) anzuzeigen und absteigend zu sortieren,
und dann verstärkte Aufmerksamkeit dem oberen Teil der Liste zu widmen, anstatt nicht funktionierende Automatismen zu bemühen,
die bei falscher Anwendung mehr schaden als sie nutzen.

Code: Alles auswählen

rpm -qa --qf '%{size}       \t%{name}\n' | sort -rn

abgewandelte Form:

Code: Alles auswählen

urpmi_rpm-find-leaves | xargs rpm -q --qf '%{size}       \t%{name}\n' | sort -rn

Auf jeden Fall ist meine Todo-Liste gerade um ein paar Punkte länger geworden ...

Meine oben geschriebene Vorgehensweise war etwas zu kurz. Hier der Link zu MU.de. Sollte in großen Teilen auch heute noch funktionieren. Nur dass man in Cauldron die initrd mit dracut erzeugen sollte...

Oliver

Hier gibt's evtl. noch hilfreiche Informationen was orphans und Minimalinstallation angeht: https://bugs.mageia.org/show_bug.cgi?id=609
Hier habe ich das generelle Problem (der fehlenden Dokumenation) auch schonmal angemerkt: https://bugs.mageia.org/show_bug.cgi?id=3163#c8


Übrigens kann man im normalen Installer in der individuellen Paketauswahl auch die --no-suggests Funktion anschalten, wenn ich mich Recht erinnere.

Erstmal vielen Dank für die Hinweise.

Beim Lesen der ersten Sätze habe ich mich an die chroot-Vorgehensweise erinnert. Sicher wäre das eine Option, wenn es nicht so aufwändig wäre. Auch der Bugreport, auf den der Doktor hinweist beinhaltet das langwierige Jonglieren mit urpmi.

Fazit:
Ich habe mir ja letztens schon einmal ein Minimalsystem ohne X auf dem gleichen Rechner gebaut - allerdings für einen anderen Zweck und ohne X. Das wäre aber jetzt keine Option, denn nach einem 'urpmi task-lxde' oder ähnlich wäre ich so weit wie jetzt auch - viel zuviel Ballast. Jetzt war mein Ziel, eine kleine Netbook-Installation zu machen, mit X und als Anwendungen nur den Browser sowie vlc, als Tools mc und die drakxtools. Das aber übersteigt anscheinend die Möglichkeiten des normalen Installers, sprich: es wird viel Handarbeit verlangt. Jetzt dachte ich, dass mit der Mageia 1 + LXDE eine Lösung da wäre. Die zeigt sich aber als instabil: heute morgen nach dem Einschalten des Netbooks ist WLAN einfach über Nacht "weg" - das System findet einfach kein Netzwerk (das Netzwerk ist da, sagt mein Notebook). Stabil ist anders, aber das ist ein anderes Thema.

An der Installation von antiX habe ich gemerkt, dass "einfach" und "schlank" keine Gegensätze sind. Ich werde mal weitersuchen oder auch versuchen, das Problem bei antiX zu lösen.

Zurück bleibt der Bug bei auto-orphans, dass hier nur Paketmanagement-interne Abhängigkeiten geprüft werden und nicht die Abhängigkeit einer Funktion vom Paket. Hier entsteht Schaden nicht nur bei falscher Anwendung.

doktor5000 hat geschrieben:Ich wäre momentan dafür, die komplette orphans-Funktionalität einfach zu deaktivieren. Entweder ganz oder gar nicht ...

Finde ich nicht. Ich finde schon, dass man davon ausgehen kann, dass jemand, der sich als root auf der Konsole rumtreibt, weiß, dass er lesen sollte, was ihm da gesagt wird. Wenn dann da steht, dass z.B. task-kde4-minimal entfernt werden soll, ist doch klar, dass man das nicht akzeptiert.
Anders sieht es aus, wenn es da ein GUI gäbe, dann müsste es definitiv noch die Möglichkeit geben, nur bestimmte Waisen zu entfernen (also eben z.B. nicht task-kde4-minimal und Dependencies, aber halt die anderen, wirklichen Waisen). So wie die Funktion bisher implementiert ist, finde ich sie aber in Ordnung (in Abgrenzung zu "schlecht", aber auch zu "super"), bei mir ist das ein sehr häufig benutzter Befehl und nach den ersten Wochen meiner Linux-Zeit, in denen ich mir dann angewöhnt habe, den Kram in Fehlermeldungen oder der Konsole auch wirklich zu lesen (unter WIndows gibt es ja so viele Pop-Ups, dass man irgendwann einfach immer sofort auf "OK" oder "Weiter" klickt), ist mir da auch nichts schief gegangen...

Edit: Und es gibt ja immer noch die Möglichkeit, die Pakete manuell in die entsprechenden Listen unter /var/lib/rpm/installed-through-deps.list einzutragen bzw. sie zu entfernen, um das Problem mit einem falschen Waisen dauerhaft zu lösen...

Trotzdem fehlt immer noch die Dokumentation über die Funktionalität. Und wenn man mal zählt, wie oft die Frage oder Probleme damit auftauchen,
bist du einer der ganz wenigen, bei dem die Funktion ordnungsgemäß funktioniert bzw. eingesetzt wird.

BTW: Man kann schon installierte Pakete einfach mittels urpmi paketname manuell markieren, damit werden sie von der auto-orphans Funktion ignoriert:

[doktor5000@mageia1 ~]$ sudo urpmi xdg-utils
Paket xdg-utils-1.1.0-0.rc1.1.mga1.x86_64 ist installiert
xdg-utils wird als manuell installiert markiert, es wird von der auto-orphan-Funktion ignoriert
writing /var/lib/rpm/installed-through-deps.list

Außerdem wurde für Mageia 2 bereits qt4urpmi importiert: http://www.mandrivauser.de/forum/viewto ... 90&t=27502

Ja klar. Ich habe da also eine Liste von über 100 angeblichen Orphans (die es direkt nach einer Systeminstallation garnicht geben dürfte). Kannst Du mir auf Anhieb sagen, welche Pakete für das Starten der Systemdienste cron daemon, up/down network, Display Manager, postfix (das waren nur einige der Dienste) verantwortlich sind, so dass ich sie dann in der grafischen Liste oder einzeln per "urpmi paket" als manuell installiert markieren kann? Unpraktisch, oder?

Wie gesagt, Doku, grafisches Frontend, alles schön, nur bleibt davon der Bug unberührt (wenn er reproduzierbar ist, wozu ich bisher keine Zeit hatte). Falls reproduzierbar, ist es ein Bug einer neuere Version von urpmi (oder was auch immer), da er unter gleichen Umständen mit Mageia 1 nicht auftrat.

Das hat IMHO mit der allgemeinen Diskussion über die Funktion nichts zu tun.