| View previous topic :: View next topic |
| Author |
Message |
MalleRIM
Guru
Joined: 23 Jul 2007
Posts: 563
Location: China
|
 Posted: Thu Jun 05, 2008 2:59 pm Post subject: portage/paludis/pkgcore - Fazit: Macken haben sie alle |
 |
|
Nachdem ich alle drei etwas kenne, wollte ich hier mal ein Fazit abgeben
Portage
++ funktioniert immer, passt immer zum Tree (was in der Natur der Sache liegt)
+ hat für fast jede Option/Operation eine Kurzform
+ am wenigsten wartungsaufwändig
- langsam
- unsauber: Pakete, die nicht mehr im tree sind, werden meist nicht angezeigt, maskierte Pakete bleiben oft ohne Meldung installiert
Pkgcore
+ etwas schneller als portage
-- scheinbar längst noch nicht ausgereift. Bei einem System musste ich die profile.env von Hand wieder herstellen; in einem chroot-Testsystem (fast komplett mit pkgcore aufgesetzt!) war gcc nur noch rudimentär vorhanden, ich musste das System löschen, da ich keine Software mehr installieren konnte. Das pkgcore das System zerschießt wird auch an anderer Stelle hier im Forum berichtet.
- build-dependencies werden bei einem --clean (--depclean äquivalent) standardmäßig mit entfernt, wenn nicht die Option -B benutzt wird. Meiner Meinnung nach keine gute Idee, da einige Ebuilds eigentliche Runtime-Dependencies fälschlicherweise als Build-Dependencies angegeben haben. Natürlich ist das nicht pkgcores Schuld, aber solange das so ist, sollte auch diese Option nicht standardmäßig aktiviert werden. Wo man die selbst deaktivieren kann, konnte ich nicht herausbekommen. Außerdem will ich meine build-dependencies gar nicht entfernen, da ich nicht bei jedem Upgrade mehr Pakete als nötig installieren und wieder deinstallieren will. Und mich darauf verlassen zu müssen, jedes mal dran zu denken, ist mir zu blöd.
Vor allem wegen des doppelten minus habe ich pkgcore nicht lange benutzt und kann daher nicht mehr darüber aussagen. Weitere Erfahrungsberichte erwünscht.
Paludis
+ wesentlich schneller als portage
+ verbesserte keyword-Verwaltung (ich habe zum Beispiel ~amd64 für mein privates Overlay akzeptiert, was sehr angenehm ist); license mask
+ erweiterbar mit hooks
+ strikt - spürt alles auf, was nicht installiert sein dürfte
+ riesiger Funktionsumfang
+ Support für neuste EAPIs (z.B. kdebuild-1, mit Use-dependency-Support)
+ Repositories - der Gentoo-Tree und alle Overlays werden gleich behandelt und alle von Paludis synchronisiert. Jedes Repository hat eine Konfigurationsdatei, in der auch die "importance" festgelegt werden kann (bei gleichen Paketnamen&Versionen wird das Paket aus dem Repository mit der höheren importance verwendet).
- relativ wenige Kurzoptionen (z.B. --dl-reinstall if-use-changed anstelle von -N)
- nervige Eigenarten: Es werden immer die Abhängigkeiten der installierten Pakete genommen, nicht die aktuellen im Repository. Wenn also x264-svn zu x264 wird und das VLC-ebuild entsprechend angepasst wird, bekommt paludis das nicht mit. Die Lösung ist, das Paket neu zu installieren oder manuell die Abhängigkeiten in /var/db/pkg zu ändern. Kann mir jemand sagen, wozu diese Unart dient?
- --uninstall-unused (--depclean äquivalent) entfernt bei geslotteten Paketen ältere Versionen nicht, solange Pakete mit darauf passenden Abhängigkeiten installiert sind. Ein manuelles Entfernen mit --permit-unsafe-uninstalls ist aber möglich und zieht keine Probleme nach sich. Benachrichtigt über potenziell nicht benötigte Pakete wird man nicht.
- kann keine Binärpakete erzeugen oder verwenden (ist aber geplant)
- fehlender ask-Support. Kann per hook nachgebessert werden.
im Moment nutze ich primär paludis und gelegentlich mal portage um geänderte Dependencies aufzuspüren oder um zu Überprüfen, ob paludis irgendwelche alten Versionen von geslotteten Paketen übergelassen hat. Im aktuellen Zustand ist es auch noch zu wartungsaufwändig für denjenigen, der den Computer "einfach nur benutzen" will. Paludis gefällt mir eigentlich besser, leider kann es für mich Portage noch nicht komplett ersetzen. Kommt ja vielleicht noch 
Last edited by MalleRIM on Sun Jun 08, 2008 4:48 pm; edited 2 times in total |
|
| Back to top |
|
 |
manuels
Advocate
Joined: 22 Nov 2003
Posts: 2146
Location: Europe
|
| Posted: Thu Jun 05, 2008 3:45 pm Post subject: |
|
|
Danke für die Übersicht. Hab noch nie was anderes als Portage genutzt, aber so kann man sich überlegen auch mal was anderes auszuprobieren.
Nach diesem Bericht schon mal nicht Pkgcore! 
_________________
Build your own live cd with catalyst 2.0! |
|
| Back to top |
|
|
revilootneg
Tux's lil' helper
Joined: 03 Jun 2007
Posts: 102
Location: /germany/hannover
|
| Posted: Thu Jun 05, 2008 9:42 pm Post subject: |
|
|
| manuels wrote: | | Danke für die Übersicht. |
++
| MalleRIM wrote: | | Kann mir jemand sagen, wozu diese Unart dient? |
Ich glaube das hat keinen Zweck, sondern muss noch implementiert werden. Ein recht ähnliches Problem ist ist die Verschiebung von Paketen (bspw. xarchiver von xfce-extra nach app-arch). Portage hat dafür einen Mechanismus, der nach einem sync zum Aktualisieren der config-files via dispatch-conf auffordert (siehe dazu auch Gunnar Wrobels Gentoo-Buch S. 207f).
Eine sicher (im allgemeinen) relativ unwichtige Funktion von portage fehlt in paludis leider:
emerge -pf <package/world/whatever> gibt eine Liste sämtlicher Server/Mirrors aus, von denen zu fetchen versucht wird. Das ist für Leute, die nicht @home fetchen können recht schön, weil damit eigenen Skripte einfach möglich sind und keine eigene Interpretation der 4. Zeile in $PORTDIR/metadata/cache/<atom-name-version> nötig wird (Ich sitze da gerade selbst dran, daher komme ich darauf). |
|
| Back to top |
|
|
Earthwings
Bodhisattva
Joined: 14 Apr 2003
Posts: 7753
Location: Germany
|
| Posted: Sun Jun 08, 2008 8:14 am Post subject: |
|
|
Moved from Deutsches Forum (German) to Diskussionsforum.
_________________
KDE |
|
| Back to top |
|
|
MalleRIM
Guru
Joined: 23 Jul 2007
Posts: 563
Location: China
|
| Posted: Sun Jun 08, 2008 4:29 pm Post subject: |
|
|
| revilootneg wrote: | | MalleRIM wrote: | | Kann mir jemand sagen, wozu diese Unart dient? |
Ich glaube das hat keinen Zweck, sondern muss noch implementiert werden. Ein recht ähnliches Problem ist ist die Verschiebung von Paketen (bspw. xarchiver von xfce-extra nach app-arch). Portage hat dafür einen Mechanismus, der nach einem sync zum Aktualisieren der config-files via dispatch-conf auffordert (siehe dazu auch Gunnar Wrobels Gentoo-Buch S. 207f). |
mit dispatch-conf lassen sich die Konfigurationsdateien von Portage anpassen (package.keywords etc.). Nicht aber die Informationen in /var/db/pkg/${CATEGORY}/${P}/. Die bleiben auch bei Portage solange gleich, bis ein Paket neu installiert/entfernt wird. Nur nutzt Portage eben diese Informationen nicht zur Abhängigkeitsauflösung, sondern greift auf das Repository zurück, aus dem das Paket installiert wurde oder nutzt den Metadaten-cache, was prinzipiell aufgrund der unwesentlich höheren Dateigröße keinen Geschwindigkeitsnachteil bringen sollte.
Übrigens, noch etwas: Paludis regeneriert die Metadaten nicht selber, beschwert sich aber, wenn dort etwas fehlt (was beispielsweise passiert, wenn man ein ebuild für eine neue Wine-Version nicht in ein Overlay gepackt hat, weil man sich sicher ist, dass sie beim nächsten synchronisieren sowieso im Tree ist). Funktionieren tut es trotzdem. Ich denke, das wird bis 1.0 noch behoben werden.
[edit]falsche Behauptung, instruo kann metadaten regenerieren[/edit]
Paludis ist auch sehr "verbose" - das bedeutet es gibt ständig Dinge aus, die den normalen User meist gar nicht interessieren. Das mag jedem selbst überlassen sein, ob das ein Vorteil ist oder nicht. |
|
| Back to top |
|
|
Genone
Retired Dev
Joined: 14 Mar 2003
Posts: 9523
Location: beyond the rim
|
| Posted: Sun Jun 08, 2008 5:25 pm Post subject: |
|
|
| MalleRIM wrote: | | mit dispatch-conf lassen sich die Konfigurationsdateien von Portage anpassen (package.keywords etc.). Nicht aber die Informationen in /var/db/pkg/${CATEGORY}/${P}/. Die bleiben auch bei Portage solange gleich, bis ein Paket neu installiert/entfernt wird. |
Falsch (das ebuild wird zwar nicht geändert, die relevanten Dateien aber schon). |
|
| Back to top |
|
|
a.b.
Apprentice
Joined: 23 Mar 2008
Posts: 218
Location: Anus Mundi, Germany
|
| Posted: Sun Jun 08, 2008 5:46 pm Post subject: Re: portage/paludis/pkgcore - Fazit: Macken haben sie alle |
|
|
| MalleRIM wrote: |
+ Support für neuste EAPIs (z.B. kdebuild-1, mit Use-dependency-Support) |
Das ist meiner Meinung ein genauso tolles "Feature" wie proprietäre Formate oder "Erweiterungen" für Formate (zum Beispiel HTML) |
|
| Back to top |
|
|
Berniyh
l33t
Joined: 07 Jun 2006
Posts: 677
|
| Posted: Fri Jun 20, 2008 12:17 am Post subject: Re: portage/paludis/pkgcore - Fazit: Macken haben sie alle |
|
|
| MalleRIM wrote: | | - nervige Eigenarten: Es werden immer die Abhängigkeiten der installierten Pakete genommen, nicht die aktuellen im Repository. Wenn also x264-svn zu x264 wird und das VLC-ebuild entsprechend angepasst wird, bekommt paludis das nicht mit. Die Lösung ist, das Paket neu zu installieren oder manuell die Abhängigkeiten in /var/db/pkg zu ändern. Kann mir jemand sagen, wozu diese Unart dient? |
Das ist weniger eine Unart, sondern vielmehr Folge des "strikter" Prinzips.
Denn für die Dependencies ist es eben entscheidend, mit was das Paket installiert wurde und nicht, was das Paket im Repository für Dependencies angibt.
Nimm mal folgenden Fall:
Du installierst foo1, welches als dep foo2 hat. Nun wird foo2 durch foo3 ersetzt, foo1 sollte mit foo3 ebenfalls funktionieren, aber es muss rekompiliert werden, um es gegen das neue Paket zu linken. Auf jeden Fall wurde foo1 nun mal mit foo2 installiert, deshalb sollte das auch die dep sein.
Du hast allerdings insofern recht, als dass die Fehlermeldung evtl. etwas klarer sein könnte, wenn die deps durch eine Neuinstallation erfüllt wären und sollte dies vorschlagen.
Prinzipiell ist es aber nicht "falsch".
| a.b. wrote: | | MalleRIM wrote: |
+ Support für neuste EAPIs (z.B. kdebuild-1, mit Use-dependency-Support) |
Das ist meiner Meinung ein genauso tolles "Feature" wie proprietäre Formate oder "Erweiterungen" für Formate (zum Beispiel HTML) |
Erläutere mal bitte, diesen Vergleich hab ich nicht wirklich verstanden…
Übrigens ist kdebuild-1 eine wirklich gute EAPI. |
|
| Back to top |
|
|
Necoro
Veteran
Joined: 18 Dec 2005
Posts: 1912
Location: Germany
|
| Posted: Fri Jun 20, 2008 7:34 am Post subject: Re: portage/paludis/pkgcore - Fazit: Macken haben sie alle |
|
|
| Berniyh wrote: | | a.b. wrote: | | MalleRIM wrote: |
+ Support für neuste EAPIs (z.B. kdebuild-1, mit Use-dependency-Support) |
Das ist meiner Meinung ein genauso tolles "Feature" wie proprietäre Formate oder "Erweiterungen" für Formate (zum Beispiel HTML) |
Erläutere mal bitte, diesen Vergleich hab ich nicht wirklich verstanden… |
Naja... der "offizielle Standard" unterstützt kdebuild-1 nicht ... also wird einfach mal der Support in Paludis eingebaut und alle können schauen wo sie bleiben... Das is halt so ähnlich wie "hmm ... der IE hat dieses tolle standard-missachtende Feature... bauen wir das doch mal ein und lachen alle aus, die einen anderen Browser benutzen"
_________________
Inter Deum Et Diabolum Semper Musica Est. |
|
| Back to top |
|
|
think4urs11
Bodhisattva
Joined: 25 Jun 2003
Posts: 6659
Location: above the cloud
|
| Posted: Fri Jun 20, 2008 7:46 am Post subject: Re: portage/paludis/pkgcore - Fazit: Macken haben sie alle |
|
|
| Necoro wrote: | | Das is halt so ähnlich wie "hmm ... der IE hat dieses tolle standard-missachtende Feature... bauen wir das doch mal ein und lachen alle aus, die einen anderen Browser benutzen" |
Microsoft Active Directory <-> LDAP wäre auch so ein Beispiel. Proprietäre Erweiterungen sind nie wirklich gut.
Nur mit dem Unterschied das MS eine entsprechend große Marktmacht hat, Paludis ist nur 1-of-3
_________________
Nothing is secure / Security is always a trade-off with usability / Do not assume anything / Trust no-one, nothing / Paranoia is your friend / Think for yourself |
|
| Back to top |
|
|
Berniyh
l33t
Joined: 07 Jun 2006
Posts: 677
|
| Posted: Fri Jun 20, 2008 7:32 pm Post subject: |
|
|
| Necoro wrote: | | Berniyh wrote: | | a.b. wrote: | | MalleRIM wrote: |
+ Support für neuste EAPIs (z.B. kdebuild-1, mit Use-dependency-Support) |
Das ist meiner Meinung ein genauso tolles "Feature" wie proprietäre Formate oder "Erweiterungen" für Formate (zum Beispiel HTML) |
Erläutere mal bitte, diesen Vergleich hab ich nicht wirklich verstanden… |
Naja... der "offizielle Standard" unterstützt kdebuild-1 nicht ... also wird einfach mal der Support in Paludis eingebaut und alle können schauen wo sie bleiben... Das is halt so ähnlich wie "hmm ... der IE hat dieses tolle standard-missachtende Feature... bauen wir das doch mal ein und lachen alle aus, die einen anderen Browser benutzen" |
Dennoch kannst du es nicht vergleichen.
Zum Einen wurde kdebuild-1 nicht gemacht, um die bisherigen EAPIs zu ersetzen, sondern, um in einem Overlay, das experimentelle packages anbietet, neue EAPI-Features, von denen die meisten dringend gebraucht werden (inzwischen wurden ja auch endlich use deps in Portage eingeführt).
Zum Anderen ist es auch unter Rücksprache mit Portage Entwicklern entstanden, sowie ist die Basis PMS und nicht direkt Paludis.
Paludis ist allerdings derzeit der Einzige Paketmanager, der kdebuild-1 unterstützt.
Die Portage Entwickler würden es evtl. unterstützen, jedoch dauert es wohl zu lange, es zu implementieren.
Die Pkgcore Entwickler haben eindeutig etwas gegen GLEP54 und 55, weshalb man davon ausgehen kann, dass sie kdebuild-1 nicht unterstützen wollen (auch wenn sie es können/könnten).
Abgesehen davon hinkt der Vergleich zu proprietären Formaten zudem, da kdebuild-1 genau dokumentiert ist und es eine PMS Version mit kdebuild-1 gibt. |
|
| Back to top |
|
|
Genone
Retired Dev
Joined: 14 Mar 2003
Posts: 9523
Location: beyond the rim
|
| Posted: Fri Jun 20, 2008 10:51 pm Post subject: |
|
|
| Berniyh wrote: | | Zum Anderen ist es auch unter Rücksprache mit Portage Entwicklern entstanden, |
Also daran kann ich mich nicht wirklich erinnern (da du von Portage Entwicklern sprichst, und ausser mir und Zac gibt es da momentan eigentlich niemanden) |
|
| Back to top |
|
|
Berniyh
l33t
Joined: 07 Jun 2006
Posts: 677
|
| Posted: Fri Jun 20, 2008 11:41 pm Post subject: |
|
|
| Genone wrote: | | Berniyh wrote: | | Zum Anderen ist es auch unter Rücksprache mit Portage Entwicklern entstanden, |
Also daran kann ich mich nicht wirklich erinnern (da du von Portage Entwicklern sprichst, und ausser mir und Zac gibt es da momentan eigentlich niemanden) |
Sorry, ich war nicht selbst dabei, aber ich bin mir zu 99% sicher, dass es da Gespräche gab.
Ist aber auch egal, ändert ja an der Situation, dass es für Portage Nutzer (bzw. für die, die Paludis nicht verwenden wollen) natürlich ungünstig ist, nichts. |
|
| Back to top |
|
|
xces
Guru
Joined: 11 Oct 2002
Posts: 515
|
| Posted: Sat Jun 21, 2008 11:57 am Post subject: Re: portage/paludis/pkgcore - Fazit: Macken haben sie alle |
|
|
| Necoro wrote: | | Naja... der "offizielle Standard" unterstützt kdebuild-1 nicht ... also wird einfach mal der Support in Paludis eingebaut und alle können schauen wo sie bleiben... |
Du übersiehst, dass Paludis für sich den Anspruch erhebt, die Paketformate mehrerer Distributionen zu unterstützen (z. B. das von Exherbo seit Neuestem...). Und in diesem Licht sieht die Implementation von zu Portage "inkompatiblen" Features doch schon wieder ganz anders aus. |
|
| Back to top |
|
|
Berniyh
l33t
Joined: 07 Jun 2006
Posts: 677
|
| Posted: Sat Jun 21, 2008 12:27 pm Post subject: Re: portage/paludis/pkgcore - Fazit: Macken haben sie alle |
|
|
| xces wrote: | | Necoro wrote: | | Naja... der "offizielle Standard" unterstützt kdebuild-1 nicht ... also wird einfach mal der Support in Paludis eingebaut und alle können schauen wo sie bleiben... |
Du übersiehst, dass Paludis für sich den Anspruch erhebt, die Paketformate mehrerer Distributionen zu unterstützen (z. B. das von Exherbo seit Neuestem...). Und in diesem Licht sieht die Implementation von zu Portage "inkompatiblen" Features doch schon wieder ganz anders aus. |
Da du das gerade ansprichst...
Im Prinzip ist kdebuild-1 ein Backport einiger Features von exheres-0 (bzw. von Features, die man da schon lange findet).
Auch paludis-1 hatte glaube ich schon einige der Features.
kdebuild-1 ist aber ein offiziell unterstütztes Projekt, im Gegensatz zu exheres-0 und paludis-1.
(Vorsicht: kdebuild-1 ist keine offiziell (im offiziellen Tree oder in PMS, wo eine Version ohne kdebuild-1 verfügbar sein muss) unterstützte EAPI! Sondern lediglich im "offiziellen" kde overlay zur live Version von KDE) |
|
| Back to top |
|
|
MalleRIM
Guru
Joined: 23 Jul 2007
Posts: 563
Location: China
|
| Posted: Sat Jun 21, 2008 7:36 pm Post subject: Re: portage/paludis/pkgcore - Fazit: Macken haben sie alle |
|
|
| Berniyh wrote: | | MalleRIM wrote: | | - nervige Eigenarten: Es werden immer die Abhängigkeiten der installierten Pakete genommen, nicht die aktuellen im Repository. Wenn also x264-svn zu x264 wird und das VLC-ebuild entsprechend angepasst wird, bekommt paludis das nicht mit. Die Lösung ist, das Paket neu zu installieren oder manuell die Abhängigkeiten in /var/db/pkg zu ändern. Kann mir jemand sagen, wozu diese Unart dient? |
Das ist weniger eine Unart, sondern vielmehr Folge des "strikter" Prinzips.
Denn für die Dependencies ist es eben entscheidend, mit was das Paket installiert wurde und nicht, was das Paket im Repository für Dependencies angibt.
Nimm mal folgenden Fall:
Du installierst foo1, welches als dep foo2 hat. Nun wird foo2 durch foo3 ersetzt, foo1 sollte mit foo3 ebenfalls funktionieren, aber es muss rekompiliert werden, um es gegen das neue Paket zu linken. Auf jeden Fall wurde foo1 nun mal mit foo2 installiert, deshalb sollte das auch die dep sein. |
Und wozu gibt's reconcilio?
btw.: ich will keinesfalls pkgcore heruntermachen. Immerhin gibt's ja auch Leute, die damit gut fahren. Bei mir ist das aber nach hinten losgegangen. pkgcore hat denke ich hohes Potential wegen der portage-Ähnlichkeit bei saubererer Codebasis. Ich werde es bei Gelegenheit wohl doch nochmal wieder probieren. Paludis ist eben auch nicht das Nonplusultra. |
|
| Back to top |
|
|
Berniyh
l33t
Joined: 07 Jun 2006
Posts: 677
|
| Posted: Sun Jun 22, 2008 6:18 am Post subject: Re: portage/paludis/pkgcore - Fazit: Macken haben sie alle |
|
|
| MalleRIM wrote: | | Berniyh wrote: | | MalleRIM wrote: | | - nervige Eigenarten: Es werden immer die Abhängigkeiten der installierten Pakete genommen, nicht die aktuellen im Repository. Wenn also x264-svn zu x264 wird und das VLC-ebuild entsprechend angepasst wird, bekommt paludis das nicht mit. Die Lösung ist, das Paket neu zu installieren oder manuell die Abhängigkeiten in /var/db/pkg zu ändern. Kann mir jemand sagen, wozu diese Unart dient? |
Das ist weniger eine Unart, sondern vielmehr Folge des "strikter" Prinzips.
Denn für die Dependencies ist es eben entscheidend, mit was das Paket installiert wurde und nicht, was das Paket im Repository für Dependencies angibt.
Nimm mal folgenden Fall:
Du installierst foo1, welches als dep foo2 hat. Nun wird foo2 durch foo3 ersetzt, foo1 sollte mit foo3 ebenfalls funktionieren, aber es muss rekompiliert werden, um es gegen das neue Paket zu linken. Auf jeden Fall wurde foo1 nun mal mit foo2 installiert, deshalb sollte das auch die dep sein. |
Und wozu gibt's reconcilio? |
Naja, zunächst ist es nunmal eine Prinzipsache, wie ich ja schon sagte.
Es ist halt die Frage, ob man gezielt Probleme, die mit reconcilio behebbar sind in Kauf nehmen will oder eben den strikteren Weg geht und das nimmt was installiert ist.
Ich finde das auch nicht so schlimm, denn die Fälle, in denen das auftaucht sind eher selten.
Nur eben die Message könnte etwas deutlicher sein.
Es sind aber (zumindest für Exherbo, vermutlich aber auch für Gentoo) meines Wissens eh bessere Lösungen für Package moves etc. geplant.
Ich meine, dass das Problem mal angeschnitten wurde.
Ach ja, noch was zu Pkgcore. Ich finde es dort sehr nervig, dass Pkgcore bei allem, was es nicht kennt sofort Backtraces ausspuckt. ^^
Portage bringt in solch einem Fall eine Warnung und versucht weiterzumachen.
Wenn ich z.B. aus unserem Overlay ein -scm Paket installiere, könnte ich danach nichts mehr mit Pkgcore machen (Deshalb kann ich zum Beispiel Pkgcore nicht mal antesten, naja, es will wohl nicht getestet werden…). |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Deutsches Forum (German) 
