Bug 467356 - plymouth packaging creates dependency loop
plymouth packaging creates dependency loop
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: plymouth (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: F10Preview
  Show dependency treegraph
 
Reported: 2008-10-16 23:20 EDT by Jeremy Katz
Modified: 2008-10-26 13:01 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-26 13:01:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jeremy Katz 2008-10-16 23:20:23 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.
Comment 1 Ray Strode [halfline] 2008-10-17 10:09:33 EDT
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?
Comment 2 Jeremy Katz 2008-10-17 10:18:53 EDT
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.
Comment 3 Ray Strode [halfline] 2008-10-17 13:34:23 EDT
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.
Comment 4 Jeremy Katz 2008-10-17 15:44:54 EDT
plymouth-libs also requires plymouth
Comment 5 Ray Strode [halfline] 2008-10-17 16:42:01 EDT
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.
Comment 6 Jeremy Katz 2008-10-21 11:43:58 EDT
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
Comment 7 Ray Strode [halfline] 2008-10-21 14:23:08 EDT
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.
Comment 8 Ray Strode [halfline] 2008-10-21 14:24:38 EDT
should be in tomorrow's rawhide.
Comment 9 Ray Strode [halfline] 2008-10-24 13:44:01 EDT
according to drago01 this still isn't working.
Comment 10 Matthias Clasen 2008-10-24 18:26:52 EDT
But the plymouth -> plymouth-libs -> plymouth loop seems to be gone, at least.
Comment 11 Jeremy Katz 2008-10-26 13:01:47 EDT
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

Note You need to log in before you can comment on or make changes to this bug.