Red Hat Bugzilla – Bug 393541
nspluginwrapper unhappy on the first install
Last modified: 2007-12-15 12:46:37 EST
Description of problem:
An installation of the first copy of nspluginwrapper ends up
with reported errors from %post script. It looks that it
tries to run
/usr/bin/mozilla-plugin-config -i -f > /dev/null 2>&1
and is unhappy about it. Possibly bug 351301 triggers that
although I am not really sure. OTOH errors do not seem to be of
any consequence so
/usr/bin/mozilla-plugin-config -i -f > /dev/null 2>&1 || :
would solve the issue.
It appears that wrapping the whole preuninstall in
'( .... ) || :' also could be a good idea. Errors are sent
to /dev/null anyway and leaving duplicates which have to
removed with 'rpm -e --noscripts ...' is not that nice.
Version-Release number of selected component (if applicable):
That's a good idea, thanks. Added to nspluginwrapper-0.9.91.5-13.fc8.
This is just a work-around to the real problem.
The real problem is that your source the firefox version at build time and use
this in your mozilla-plugin-config script.
So if firefox is updated, and you dont rebuild nspluginwrapper, then the
mozilla-plugin-config script is going to fail for any user who tries to install
nspluginwrapper with the new version of firefox.
You need to find some way of properly finding the libraries in your config
script without depending on a firefox version number at build time.
pkg-config --modversion firefox-plugin
^^ is there any reason why this command cannot be run from the
mozilla-plugin-config script instead of the spec file?
pkg-config and firefox-devel (necessary for it to work) are not installed on
normal user systems.
I suppose the same information can be obtained with firefox --version, correct?
> I suppose the same information can be obtained with firefox --version,
Not entirely. It looks like 'firefox --version' requires well-defined
$DISPLAY while mozilla-plugin-config can run in a context where this
is not defined.
OTOH I see what you mean. nspluginwrapper-0.9.91.5-12.fc8 is already
broken in F8 because mozilla-plugin-config has the following code
if [ ! -x $MOZ_LIB_DIR/firefox-126.96.36.199/firefox-bin ]; then
..... and so on ...
while the current version of firefox is firefox-188.8.131.52-2.fc8
Still the code like
firefoxdir=$(dirname $(echo $MOZ_LIB_DIR/firefox-*/firefox-bin))
[ -d "$firefoxdir" ] || exit 1
in mozilla-plugin-config should work just fine (unless we want
to guard against mulitiple firefox versions present so then
'stat --format %Y ...' on firefox-bin found and pick up the newest).
Does the above mean that plugins has to be rewrapped if a firefox
version changes? What about other browsers?
Upon reflection - comments by Chris Stone say that in the
current nspluginwrapper packages mozilla-plugin-config is broken.
The above is correct but this is another issue and the original
report was really about that package scripts should not end up
with a non-zero status, regardless of what mozilla-plugin-config
got on exit - for good or bad reasons. That is the case too.
The fact that nspluginwrapper looks like tied up to a specific
version of firefox (and why only firefox?) should be handled
in another bug report. Is there one already?
It appears that an answer to a question from the previous comment
is "no". So I added bug 420471 (with a proposed fix).
Please read my comment 2 of Bug 351301.
libjavaplugin.so uses xpcom (gecko) libs but nspluginwrapper doesn't support it
on Fedora 8. So this is the reason why the error is reported.
Then I guess the reopening of this bug has to do with the fact that the -13
release was never pushed. Had the -13 release been available it would have
saved my time and a whole lot of other peoples time.
Please push the fix for this bug to F-8. Thank you.
I apologize for being crass in comment #10, been a rough upgrade experience for
me. Thank you for being expedient. :)
No worries. If our userbase didn't tell us what they thought, we'd probably
have no users. Thanks for the feedback.
nspluginwrapper-0.9.91.5-13.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.