Bug 393541 - nspluginwrapper unhappy on the first install
nspluginwrapper unhappy on the first install
Product: Fedora
Classification: Fedora
Component: nspluginwrapper (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Martin Stransky
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2007-11-20 21:48 EST by Michal Jaegermann
Modified: 2007-12-15 12:46 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-12-15 12:46:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2007-11-20 21:48:45 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):
Comment 1 Martin Stransky 2007-12-06 07:24:34 EST
That's a good idea, thanks. Added to nspluginwrapper-
Comment 2 Christopher Stone 2007-12-10 20:20:53 EST
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.
Comment 3 Christopher Stone 2007-12-10 20:24:29 EST
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?
Comment 4 Warren Togami 2007-12-10 21:37:32 EST
pkg-config and firefox-devel (necessary for it to work) are not installed on
normal user systems.
Comment 5 Christopher Stone 2007-12-10 22:31:29 EST
I suppose the same information can be obtained with firefox --version, correct?
Comment 6 Michal Jaegermann 2007-12-11 01:13:45 EST
> I suppose the same information can be obtained with firefox --version,
> correct?

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- is already
broken in F8 because mozilla-plugin-config has the following code
   if [ ! -x $MOZ_LIB_DIR/firefox- ]; then
      ..... and so on ...
while the current version of firefox is firefox-

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?
Comment 7 Michal Jaegermann 2007-12-11 11:44:20 EST
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?
Comment 8 Michal Jaegermann 2007-12-11 15:43:59 EST
It appears that an answer to a question from the previous comment
is "no".  So I added bug 420471 (with a proposed fix).
Comment 9 Martin Stransky 2007-12-11 15:53:45 EST
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.
Comment 10 Christopher Stone 2007-12-11 21:02:04 EST
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.
Comment 12 Christopher Stone 2007-12-13 19:11:52 EST
I apologize for being crass in comment #10, been a rough upgrade experience for
me.  Thank you for being expedient. :)
Comment 13 Christopher Aillon 2007-12-14 06:59:54 EST
No worries.  If our userbase didn't tell us what they thought, we'd probably
have no users.  Thanks for the feedback.
Comment 14 Fedora Update System 2007-12-15 12:46:36 EST
nspluginwrapper- has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

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