Red Hat Bugzilla – Bug 467356
plymouth packaging creates dependency loop
Last modified: 2008-10-26 13:01:47 EDT
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
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
and the order would be
plymouth-libs -> plymouth-plugin-label -> plymouth-plugin-spinfinity -> plymouth
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
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.
and plymouth-scripts only has a
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:
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