The way that plymouth is packaged/determines the default plugin ends up leading to a fairly unavoidable dependency loop. The loop then gets snipped when ordering the rpm transaction and the default plugin gets installed "later", possibly after the kernel. Which means that you always end up with the text plugin rather than the graphical one. The problem comes in because plymouth requires system-plymouth-plugin. The providers of system-plymouth-plugin call plymouth-set-default-plugin in their %post and thus Requires(post): plymouth. Hence, loop. Honestly, I'm not sold that trying to completely genericize the default plugin really works even as is. For someone to get a different default plugin, they either have to a) exclude the plugins from the main package or b) give their plugin package a shorter name. Which seems a bit hacky at best. And given that we're not including logos in the plugin package itself, we may just be better off having the plugin selection code in plymouth-populate-initrd doing 1) Look for default.so -- if it exists, use that 2) Look for what we set as the default in the script itself 3) Always include details + text (as we do now) And then do away with the plymouth-set-default-plugin bits. That would solve this as well as simplify the logic quite a bit and make things more deterministic.
well the idea is that respins can just put -plymouth-plugin-spinfinity plymouth-plugin-olpc or whatever and then don't need to rebuild plymouth. If we encode the defaults in the populate script itself (and make it a configure time option) then I don't think that would work. Maybe we should put plymouth-set-default-plugin into plymouth-libs ? So plymouth would Requires: system-plymouth-plugin and spinfinity would Requires(post): plymouth-libs and the order would be plymouth-libs -> plymouth-plugin-label -> plymouth-plugin-spinfinity -> plymouth Sound good?
Still ends up a lengthy loop as plymouth requires plymouth-libs And my suggestion would work for the case you have, the %post of plymouth-plugin-olpc could just do if ! -f plymouthdir/default.so ln -s olpc.so plymouthdir/default.so fi And fwiw, right now, spinfinity isn't the plugin being pulled in. Because solar is shorter than spinfinity.
What's the loop? We'll end up with: 1) plymouth-plugin-spinfinity requires plymouth-libs 2) plymouth requires plymouth-libs and plymouth-plugin-spinfinity There's a cut-and-paste bug with solar. we should figure out which one will be the default and only have it have the provides.
plymouth-libs also requires plymouth
Okay I've moved plymouth-update-initrd, plymouth-populate-initrd, and plymouth-set-default-plugin to a plymouth-scripts package. Plymouth does Requires(post): plymouth-scripts and plymouth-plugin-spinfinity does Requires: /usr/sbin/plymouth-set-default-plugin and plymouth-scripts only has a Requires: nash Should be set now, so closing. If I'm being dense and still missing something, please reopen.
The loop is still there and so plymouth-plugin-spinfinity still gets installed far later as the loop gets snipped by rpm itself. 41862:D: removing plymouth-0.6.0-0.2008.10.17.3.fc10.i386 "Requires: system-plymouth-plugin >= 0.6.0-0.2008.10.17.3.fc10" from tsort relations. 41863:D: plymouth-0.6.0-0.2008.10.17.3.fc10.i386 Requires: system-plymouth-plugin >= 0.6.0-0.2008.10.17.3.fc10 41864:D: removing plymouth-plugin-spinfinity-0.6.0-0.2008.10.17.3.fc10.i386 "Requires: plymouth-plugin-label" from tsort relations. 41865:D: plymouth-plugin-spinfinity-0.6.0-0.2008.10.17.3.fc10.i386 Requires: plymouth-plugin-label 41866:D: removing plymouth-plugin-label-0.6.0-0.2008.10.17.3.fc10.i386 "Requires(auto): libply.so.1" from tsort relations. 41867:D: plymouth-plugin-label-0.6.0-0.2008.10.17.3.fc10.i386 Requires(auto): libply.so.1 41868:D: removing plymouth-libs-0.6.0-0.2008.10.17.3.fc10.i386 "Requires: plymouth = 0.6.0-0.2008.10.17.3.fc10" from tsort relations. 41869:D: plymouth-libs-0.6.0-0.2008.10.17.3.fc10.i386 Requires: plymouth = 0.6.0-0.2008.10.17.3.fc10
So to be clear the cycle is: plymouth requires plymouth-libs requires plymouth I'll drop that last requires, which seems sort of backward anyway.
should be in tomorrow's rawhide.
according to drago01 this still isn't working.
But the plymouth -> plymouth-libs -> plymouth loop seems to be gone, at least.
Yeah, we now just have 41670:D: removing plymouth-plugin-label-0.6.0-0.2008.10.24.1.fc10.i386 "Requires : plymouth = 0.6.0-0.2008.10.24.1.fc10" from tsort relations. 41671:D: plymouth-plugin-label-0.6.0-0.2008.10.24.1.fc10.i386 Requires: plym outh = 0.6.0-0.2008.10.24.1.fc10 41672:D: removing plymouth-0.6.0-0.2008.10.24.1.fc10.i386 "Requires: system-plym outh-plugin >= 0.6.0-0.2008.10.24.1.fc10" from tsort relations. 41673:D: plymouth-0.6.0-0.2008.10.24.1.fc10.i386 Requires: system-plymouth- plugin >= 0.6.0-0.2008.10.24.1.fc10 41674:D: removing plymouth-plugin-spinfinity-0.6.0-0.2008.10.24.1.fc10.i386 "Req uires: plymouth-plugin-label" from tsort relations. 41675:D: plymouth-plugin-spinfinity-0.6.0-0.2008.10.24.1.fc10.i386 Requires: plymouth-plugin-label Note: things like this are part of why excessive package splitting is harmful. In any case, if we change the plugins to require -libs then we end up with plymouth requires plugins and -libs -libs requires nothing plugins require -libs and each other Which I've done a test build and then made sure it doesn't stick new loops into the equation. It looks good, so I'm committing and building for tomorrow's rawhide