111898 - XPInstallation fails for mozilla builds after chrome.rdf introduction

Status: VERIFIED DUPLICATE of bug 109044

(SeaMonkey :: Installer, defect)

Description

[Neil Pryde]

I'm unable to install MultiZilla on mozilla builds after november 21. All
mozilla builds after this date use the new chrome file chrome.rdf This file
replaces the prior all-*.rdf files.

Don't tell me that you have to change rdf files to get it installed again.

I've set the severity to critical because all MultiZilla users will be unable to
install the new MultiZilla versions with a recent mozilla build. In fact, it's
more like a real blocker to us.

-Neil.

Comment 1

[Neil Pryde]

I think this has something to do with this bugzilla report: 

http://bugzilla.mozilla.org/show_bug.cgi?id=109488


What can we do to make it work again?

Comment 2

[Neil Pryde]

Please consider to read this bug report for more information:
http://mozdev.org/bugs/show_bug.cgi?id=682

Comment 3

[Daniel Veditz [:dveditz]]

Don't see how this is an install problem. I couldn't download the install .xpi
to check your script but the registerChrome() command shouldn't care about the
format the chrome registry keeps its files.

Comment 4

[Neil Pryde]

Our XPInstall package worked untill this chrome.rdf file is introduced. We have
not change a bit after it is introduced. If we use mozilla builds without the
chrome.rdf change, than everything is working again! 

"I couldn't download the install .xpi" use this link:

http://multizilla.mozdev.org/xpi/multiviews-095.xpi

and press shift to open your file dialog.

-Neil.

Comment 5

[Daniel Veditz [:dveditz]]

Thanks, I found the link before, the server just wasn't serving it or something.
It's working now.

You've shown no evidence that XPInstall is failing to do what your script tells
it to do -- the install.log output (of a single install!) would be helpful. In
general, though, if your package fails to work because some other part of
Mozilla has changed (for example, this happens all the time when non-frozen
interfaces change) then take it up with the folks who changed that part of Mozilla.

The install script looks pretty safe and other than the file name change in the
chrome registry (which the install doesn't directly manipulate) there haven't
been any chrome changes that I see. Things to investigate:

- do your files get unpacked in the correct place (I assume so)
- does the install run without errors (I assume so)
- does the output in installed-chrome.txt look like the right format
- if you then delete chrome.rdf does it get regenerated correctly
  including your data (would indicate a timestamp checking problem)
- if you remove the DELAYED_CHROME flag from the script does it work?

Comment 6

[Neil Pryde]

Attachment: install.log

Clean install.log without errors

Comment 7

[Neil Pryde]

- do your files get unpacked in the correct place (I assume so)
  ->Yes
- does the install run without errors (I assume so)
  ->Yes
- does the output in installed-chrome.txt look like the right format
  ->Yes, and this are the lines:

content,install,url,jar:resource:/chrome/multiviews.jar!/content/multiviews/
skin,install,url,jar:resource:/chrome/multiviews.jar!/skin/modern/multiviews/
locale,install,url,jar:resource:/chrome/multiviews.jar!/locale/en-US/multiviews/

- if you then delete chrome.rdf does it get regenerated correctly
  including your data (would indicate a timestamp checking problem)
  ->No

Comment 8

[Neil Pryde]

Aha, we have a winner! Everything seems to work, after removing the
DELAYED_CHROME flag. This is how it now looks:

// registerChrome( CONTENT | DELAYED_CHROME, getFolder(G_CHROME, G_JAR_FILE),
G_CONTENT );
// registerChrome( SKIN    | DELAYED_CHROME, getFolder(G_CHROME, G_JAR_FILE),
G_SKIN    );
// registerChrome( LOCALE  | DELAYED_CHROME, getFolder(G_CHROME, G_JAR_FILE),
G_LOCALE  );

registerChrome( CONTENT, getFolder(G_CHROME, G_JAR_FILE), G_CONTENT );
registerChrome( SKIN, getFolder(G_CHROME, G_JAR_FILE), G_SKIN    );
registerChrome( LOCALE, getFolder(G_CHROME, G_JAR_FILE), G_LOCALE  );

So it looks like a real XPInstall problem to me.

-Neil.

Comment 9

[Anders Åge Larsen]

Neil: 

Now, this report is kinda old I know, but I just wanted to know if it is still a
valid one, as it still is open. Could you please let us know if you still
experience this problem with a recent Moz build (Moz1-RC1 or a new nightly
build)? If not, could you please resolve this? 

Comment 10

[HJ]

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

Comment 11

[K'Trina Medina]

Verified as a dupe of bug 109044