106701 - prefbar install fails on Debian unless DELAYED_CHROME used

Status: VERIFIED DUPLICATE of bug 109044

(SeaMonkey :: Installer, defect)

Description

[Tsukasa Maruyama]

On Debian GNU Linux,
I want to install "Preferance Toolbar"
http://www.xulplanet.com/downloads/view.cgi?category=applications&view=prefbar
I have got and install 'prefbar.xpi', but don't show Preferance Toolbar.

I see install.log.

=====================================
 Preferences Toolbar
     -------------------

     [1/2]      Installing: /home/hideo/mozilla/chrome/prefbar.jar
     [2/2]      Register Content: jar:resource:/chrome/prefbar.jar!/content/prefbar/

     Install **FAILED** with error -239

     Install **FAILED** with error -239
     Finished Installation  10/25/2001 22:27:43

======================================================

Then, I change the package install.js
======================
- registerChrome(CONTENT, getFolder("Chrome", "prefbar.jar"), "content/prefbar/");
+ registerChrome(CONTENT | DELAYED_CHROME, getFolder("Chrome", "prefbar.jar"),
"content/prefbar/");
======================
It's Installation success!

I tried another linux distribution, Vine Linux 2.1.5 (Japanese Distoribution
based RedHat 6.2), then no problem!

Why Debian Gnu Linux cannot install success?
depend X or/and GTK+ version?

Please try install each unix system, as RedHat 7.2...

Comment 1

[Tsukasa Maruyama]

Original Report is http://bugzilla.mozilla.gr.jp:
http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=1097

Comment 2

[Daniel Veditz [:dveditz]]

Updating summary to better reflect my understanding of the specific bug, was 

  cannot install xpi package without "DELAYED_CHROME" in install.js

DELAYED_CHROME tells the install script to write the information into the
installed-chrome.txt file to be registered on next startup, instead of
registering it right away. It's mostly unnecessary; if you can't explain exactly
why you need to use that mode then you don't.
You don't say whether the chrome itself installed correctly even with the
delayed_chrome mode. -239 is a chrome registration error, and by writing into
installed-chrome.txt that doesn't mean the error won't occur, it just means we
won't know about it at install time.
Since this same package script apparently works on other platforms, I initially
suspect a directory permission problem, although in that case I would also
expect a failure from the addDirectory().

Comment 3

[Tsukasa Maruyama]

> I initially
> suspect a directory permission problem, although in that case I would also
> expect a failure from the addDirectory().

Well, installed-chrome.txt all-pacages.rdf permission It was 644. Mozilla has
installed in ~/ following.

Comment 4

[K'Trina Medina]

I don't have Debian to try to reproduce this. Tsukasa, is this still happening?

Comment 5

[Tsukasa Maruyama]

same problem bug 109044?

Comment 6

[Andrea]

Yes, it seems the same bug seen on bug 109044.
Tested with 0.9.8 release, under SuSE 7.1

The first, and most obvious question is "why only on selected machines(TM)"?

Comment 7

[Tom Mraz]

Making it duplicate as the other bug has more comments and it is plussed

*** This bug has been marked as a duplicate of 109044 ***

Comment 8

[K'Trina Medina]

Verified as a dupe of bug 109044