Description of problem:
When no plymouth theme is set, 'plymouth-set-default-theme' returns ".plymouth",
and that causes errors in 'plymouth-populate-initrd', because the latter expects
blank output from 'plymouth-set-default-theme' in this case.

(And when 'plymouth-populate-initrd' soldiers on instead of exiting, the error
message it ultimately produces is somewhat nonsensical.)

README FIRST:
Despite the verbosity of this report, the fix is trivial -- see FIX in
"Additional info" below.

--------------------------------------------------------------------------------
Version-Release number of selected component (if applicable):
plymouth-scripts-0.8.2-3.fc13.i686

--------------------------------------------------------------------------------
How reproducible:
100%

Steps to Reproduce:
Some conditions have to be met:
    1. The contents of /etc/plymouth/plymouthd.conf have to be original, i.e.:

	# Administrator customizations go in this file
	#[Daemon]
	#Theme=fade-in

    2. Package plymouth-theme-charge has to be *not* installed (reason is given
       at end of "Additional info" below).

    3. /usr/share/plymouth/themes/default.plymouth must not exist (typically
       a symlink to something like text/text.plymouth, set automagically by
       something I haven't figured out yet; it didn't happen at my F13 OS
       installs).

Then, run (with no args):
plymouth-set-default-theme

--------------------------------------------------------------------------------
Actual results:
.plymouth

As a result, when 'plymouth-populate-initrd' is run during a kernel upgrade,
it produces:

    grep: /usr/share/plymouth/themes/.plymouth/.plymouth.plymouth: \
	No such file or directory
    The default plymouth plugin () doesn't exist

--------------------------------------------------------------------------------
Expected results:
No output -- that is what 'plymouth-populate-initrd' expects when no default
theme is set (see "Additional info" below).

--------------------------------------------------------------------------------
Additional info:
(I haven't given full pathnames of the scripts involved, for brevity; they're
easily found with 'locate' or 'rpmls'.)

FIX:
Just add double quotes around the first arg (the readlink return) in
the basename call in the get_default_theme function in
'plymouth-set-default-theme'.
There's a patch attached that does this.  (Just as a matter of coding practice
it also does the same thing to an earlier instance of 'basename', but that's
not strictly necessary.)
UPDATE: I can't attach the patch -- the aptly-named *bug*zilla interface insists
that I choose a method of choosing content-type, yet there seems to be no way
to do that.  I'll add a comment later with the patch.
Note that in the F12 version there are further instances of 'basename' that
should also be fixed.

For those interested in the pathology:

The problem lies in the following code from 'plymouth-set-default-theme' (in
  function get_default_theme):

  THEME_NAME=$(basename \
    $(readlink ${PLYMOUTH_DATADIR}/plymouth/themes/default.plymouth) .plymouth)

which returns ".plymouth" if .../default.plymouth does not exist (basename sees 
".plymouth" as its only argument).

The problem caused by using ".plymouth" in 'plymouth-populate-initrd' is shown
in the following code from that script.  It does not work as intended; it
expects a blank return from 'plymouth-set-default-theme' when no theme is set:

  ... PLYMOUTH_THEME_NAME=$(plymouth-set-default-theme)
  ...
  if [ -z "$PLYMOUTH_THEME_NAME" ]; then
      echo "No default plymouth plugin is set" > /dev/stderr
      ...

(BTW, "No default plymouth theme is set" would be more to the point.)
                           ^^^^^
Why the plymouth-theme-charge package has to be not installed:
  If /usr/share/plymouth/themes/charge/charge.plymouth exists,
  that will be reported as the default theme (being set as such
  in /usr/share/plymouth/plymouthd.defaults).

--------------------------------------------------------------------------------