GentooForum.de

Hallo Leute,

seit ca. einer Woche habe ich meinen PC auf sys-apps/paludis. Inzwischen bin ich soweit, dass ich damit alles machen kann, wie mit sys-apps/portage. Daher möchte ich hier mal die Unterschiede aufschreiben.

Konfiguration
Die Dateien /etc/make.conf, /etc/make.profile und alles unter /etc/portage hat für paludis keine Bedeutung. Paludis hat alle Konfigurationsdateien unter /etc/paludis. Es gibt jedoch ein Migrationsskript portage2paludis.bash, der aus Portage-Dateien die Paludis Dateien generiert. Diese sollten trotzdem nochmal kontrolliert werden.

Ein Paar Dinge, die man unter Paladius konfigurieren kann:

Profil wird pro Repository eingestellt. Jedes Overlay kann also ein eigenes Profil haben.

/etc/paludis/package_mask.conf


/etc/paludis/keywords.conf.d/spiele.conf


Sync
Paludis unterscheidet nicht zwischen Portage und den Overlays. Daher werden mit "paludis --sync" alle Repositories aktualisiert.
Mit einem mitgelieferten Hook kann man auch die Änderungen wie bei "eix-sync" anzeigen lassen. Interessant ist auch die Option, die Repositories parallel zu aktualisieren.

System Update
Früher hatte ich "emerge -uvatDNj world" verwendet. "-a" hat paludis nicht. Man muss also immer zwei mal den Befehl starten, mit "-p" und anschließend ohne. Für "-DN" gibt es entsprechende Parameter, die die Update-Auswahl beienflussen. Genauer gesagt hat paludis noch weitere Parameter. Einen zusätzlichen Parameter für Live-Ebuilds nutze ich jetzt: "--dl-reinstall-scm weekly"

System bereinigen
Bei Portage ist es "emerge -va --depclean". Bei Paludis ist es "paludis --uninstall-unused"

Tools:
Pakete finden (eix)
Paludis hat "inquisitio". Dieser Such-Befehl liefert zwar ähnlich viele Infos wie "eix", jedoch mit der Geschwindigkeit von "emerge -S".

Revdep Rebuild
-> reconcilio

etc-update /dispatch-conf / cfg-update
-> bleibt beim alten

elogv
-> Die Ausgabe der Logs am Ende eines Installationsvorganges kann mit einem mitgelieferten Hook aktiviert werden. elogv oder elogviewer gibt es so nicht. Ich habe mir die Mühe gemacht und das Script "elogv" selbst an paludis angepasst.

eix-test-obsolete
-> config-decruft aus app-paludis/paludis-scripts::keruspe
Viel genauer und besser. Meine selbst gebauten Skripte haben jetzt auf dem PC ausgedient, da mit config-decruft abgedeckt.

genlop
-> pint.rb ebenfalls aus app-paludis/paludis-scripts::keruspe

Paludis und Vserver
Da Paludis das Erstellen und verwenden von Binärpaketen noch nicht beherrscht, müsste man alle Pakete für jeden Vserver neu bauen. Außerdem gibt es nur den Wrapper "vemerge" und kein "vpaladius". Hier empfehle ich also bei "emerge" zu bleiben.

Paludis und Crossdev
Mit ein Paar Anpassungen läßt sich die mir "crossdev" generierte Toolchain auch mit Paludis aktuell halten.
Paludis selbst kann auch irgendwie die Umgebungsvariable "ROOT" auswerten. Die neuere crossdev-Versionen bringen jedoch gute emerge-Wrapper mit Konfigurationsgenerator für die Toolchains, die ich weiterhin nutzen möchte.
Also, die Toolchain selbst mit Paludis wie alle anderen Pakete auch aktuell halten. Die Target-Systeme erstmal weiterhin mit cross-emerge bauen.

Fazit
Ich habe bisher nur den PC umgestellt. Der Laptop, der Router und der Media-Server bleiben erstmal bei Portage. Paludis ist gut, wenn man viele Overlays nutzt. Auf der anderen Seite ist sys-apps/portage Stable und auf jedem Gentoo System immer vorhanden. Daher würde die Umstellung anderer Systeme nur Aufwand bedeuten, ohne einen nennenswerten Vorteil auf der anderen Seite.

Falls jemand sich überlegt auf Paludis zu gehen sei es noch erwähnt, dass es auch sys-apps/pkgcore gibt. Diesen habe ich noch nicht getestet, scheint jedoch auch ziemlich mächtig zu sein.

Naja, sobald wird es nicht sein:

Zitat

Useful Functionality milestone contains all of the things that have to be done before we remove the paludis client.

Also erst, wenn Cave (fast) alles kann, was auch Paludis kann, und das kann dauern..

Ich sehe in Cave keinen Ersatz, sondern eine Weiterentwicklung von Paludis, und ich finde es gut, wenn eine Software auch konzeptionell überarbeitet wird. Wenn ich es richtig sehe, wird nicht das komplette Paludis-Framework überarbeitet und durch den Cave abgelöst, sondern nur der Installer-Client.

Ein Nachtrag.Nach dem Vorfall mit Paludis+Prelink bin ich wieder bei Portage.

Heute habe ich von Josef.95 erfahren, dass das aktuelle Portage 2.2 auch schon die erweiterte Syntax für die Overlays / Repositories kennt.
/etc/portage/package.mask

/etc/portage/package.keywords

Das alles funktioniert jetzt auch mit Portage (unstable)

Es geht sogar
/etc/portage/package.keywordswas Paludis damals noch nicht konnte

Also, ab morgen stelle ich alles auf Portage 2.2 um. Wer mir folgen will, beachte: es gilt noch als "unstable" (so als kleine Warnung).

Zitat von »Furry«

Mich stört aber, dass man nicht paladius und portage gleichzeitig benutzen kann, so wie das unter Debian mit apt und aptitude funktioniert.

Dies ist kein guter Vergleich, denn bei Debian ist der eigentliche Paketmanager "dpkg". Die beiden Tools sind nur Frontends dazu, die beide "dpkg" nutzen.
Paludis, wie auch pkgcore ersetzen jedoch komplett Portage, quasi als ob bei Debian eine "dpkg" Alternative gäbe.