Because of an apparent think-o in the script, if a custom theme
has a broken symlink in it, plymouth-populate-initrd would silently
stop processing files and ship an incomplete set of data files.
This commit changes "break" to "continue" so that broken symlinks
are ignored, which was probably the original intent.
It's important to make sure the theme name is properly
quoted when passed to the basename command. This
is because, if the theme name is empty we want the empty
string returned, not the suffix that would otherwise be
stripped off.
Some discussion here:
https://bugzilla.redhat.com/show_bug.cgi?id=606634
Now that the daemon looks for the default theme in configuration
files, we should make plymouth-set-default-theme write the
configuration files instead of doing symlinks.
That's what this commit does.
The scripts hard-coded the paths for LIBEXECDIR and DATADIR, unless
passed as environment variables. Instead of doing this, which breaks
if plymouth is installed outside of /usr, set these derived from the
configure $libexecdir and $datadir variables just as we do for
pkg-config, etc.
Since we use so many variables, it makes more sense to generate these
scripts from config.status rather than having special Makefile rules
for them.
Splashes aren't just shown for "boot" so including "boot" in
the name isn't right. Also, right now we link against libpng
even if we don't have any splash that uses it. This is the first
step toward making libpng only get linked to graphical splashes.
We'll need to move the graphical bits to their own library to
complete the process.
When running new, unfamiliar commands I usually invoke them with
--help to see what options they have. For plymouth-set-default-theme,
there is no --help option which I find a bit confusing, especially
since the usage is not straight-forward.
There is now an additional function "show_help" which displays an
help output when invoking plymouth-set-default-theme with --help.
Much of this code comes directly from ply-frame-buffer in libply,
but shoehorned to fit into the renderer plugin interface.
One improvement over the old code is it tracks VT changes, and
stops drawing when the wrong VT is active.
We've been using the inst function provided by mkinitrd
to install plymouth and its dependencies into the initrd
root, but mkinitrd may not be installed in a dracut world,
and dracut has its own inst function.
This commit tries getting access to either of them, before
bailing. At some point we may want to bundle our own inst
function or get a new flag added to /usr/bin/install to do
what inst does.
One useful way to use plymouth is by installing it into
an auxillary initrd image, that overlays the primary one.
This allows plymouth and its current theme to get updated
indepedently of the kernel and the rest of the initrd
stuff.
plymouth-generate-initrd creates an initrd named:
initrd-plymouth.img
in /boot that is suitable for use a second initrd on
the initrd line in grub.conf.
Previously, we'd try to guess the plugin path based
on the arch of the running process. That's sort of
fragile, so better to just install plugins where
plymouth says it's going to look for them.
Some of the plugins (well, the glow plugin) would be a lot more
versatile if they could be reused for multiple splashes with different
images.
This commit splits boot splashes into two parts, the plugin engine which
does all the dirty work, and the theme which says which plugin to use
and optionally how the plugin should work (using plugin specific
key/value pairs)
Normally when a user runs plymouth-set-default-plugin
to change which plugin plymouth uses, the change doesn't
take effect until a new kernel is installed and the initrd
is rebuilt.
This new --rebuild-initrd argument forces the currently
running initrd to get rebuilt immediately (bug 18297).
Previously, plymouth was installed in /usr/bin and
we'd look for it there to figure out if this is a
64-bit or 32-bit install. Now it's in /bin, so we
need to look in /bin instead.
Since we may be calling plymouth before /usr is
mounted we need to make sure it's not in /usr.
The daemon could technically stay in /usr/libexec,
but if we're moving the client, should move the
daemon, too, I guess.
