332203 - Ensure the installers work with MOZ_XUL_APP set on SeaMonkey

Status: RESOLVED WONTFIX

(SeaMonkey :: Installer, defect)

Description

[Mark Banner (:standard8)]

When we switch over to being a MOZ_XUL_APP we'll need to have made sure that the installers will install all the files we need. This bug is the one that will capture the necessary changes.

Comment 1

[Mark Banner (:standard8)]

Attachment: Add missing items for unix based systems part 1

This patch adds the missing items for unix based systems. This gets suiterunner to a state where it can actually run and work to a similar standard as developer builds. Note that this doesn't include items for DOM Inspector - I haven't got the xpi successfully installing yet, but this at least will get us running on linux.

Comment 2

[Andrew Schultz]

Comment on attachment 225910 [details] [diff] [review]
Add missing items for unix based systems part 1

>-bin/chrome/modern.jar
>-bin/chrome/classic.jar

These need to stay so that non-toolkit builds continue working.

Comment 3

[Mark Banner (:standard8)]

(In reply to comment #2)
> (From update of attachment 225910 [details] [diff] [review] [edit])
> >-bin/chrome/modern.jar
> >-bin/chrome/classic.jar
> 
> These need to stay so that non-toolkit builds continue working.
> 
They do - they are just moved up the file a little bit so that all the theme related items are together.

Comment 4

[Andrew Schultz]

Comment on attachment 225910 [details] [diff] [review]
Add missing items for unix based systems part 1

Right!

In addition to what you've added, I see (on nye suiterunner):
bin/components/FeedProcessor.js
bin/components/libmozgnome.so
bin/components/libsuiteprofile.so
bin/components/mozgnome.xpt
bin/components/nsBrowserContentHandler.js
bin/components/nsDefaultCLH.js
bin/components/nsExtensionManager.js
bin/components/pluginGlue.js
bin/chrome/app-chrome.manifest

You added these (which is good!), but they aren't associtated with MOZ_XUL_APP.  We should be packaging them in non-suiterunner builds (trunk and branch)
bin/components/xuldoc.xpt
bin/components/xultmpl.xpt
bin/components/xremoteservice.xpt

And you have libsuite.so, which I don't see in components/.  I'm guessing that was supposed to be libsuiteprofile.so.  :)

Comment 5

[Mark Banner (:standard8)]

(In reply to comment #4)

> In addition to what you've added, I see (on nye suiterunner):
> bin/components/nsBrowserContentHandler.js
> bin/components/nsExtensionManager.js

These are already in the file elsewhere

> bin/components/nsDefaultCLH.js
> bin/components/pluginGlue.js

Opps, new I kept on forgetting to add some. Actually, nsDefaultCLH.js probably isn't required, as nsBrowserContentHandler.js should do its job, but we'll include it just in case.

> bin/chrome/app-chrome.manifest

This is a file ff & tb don't package, so I assume we don't need to either:
http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/installer/packager.mk#224

> You added these (which is good!), but they aren't associtated with MOZ_XUL_APP.
>  We should be packaging them in non-suiterunner builds (trunk and branch)
> bin/components/xuldoc.xpt
> bin/components/xultmpl.xpt
> bin/components/xremoteservice.xpt

Ok I'll move them.

> 
> And you have libsuite.so, which I don't see in components/.  I'm guessing that
> was supposed to be libsuiteprofile.so.  :)
> 
Well actually, it will be libsuite.so once the patch on bug 329744 has been implemented... I'll change it to libsuiteprofile.so for now.

Comment 6

[Andrew Schultz]

Comment on attachment 225910 [details] [diff] [review]
Add missing items for unix based systems part 1

> These are already in the file elsewhere

So they are.  Can you move them into one of the MOZ_XUL_APP blocks?

Looking at the firefox package, I notice they also don't package nsDefaultCLH.js (even in the non-installer tarball), although I don't see anything that prevents it.

So the patch is OK with stuff moved around (although I'd like to know what's up with nsDefaultCLH.js)

I'm also remembering now that the installer runs

./run-mozilla.sh ./regxpcom
and
./run-mozilla.sh ./regchrome

after installation.  The new way to do that is "seamonkey -register", right?  suiterunner still has regxpcom, but doesn't even have regchrome.  I don't know how to handle that without breaking the XPFE installer.  We'd need a different config.ini.  The firefox installer fires up the full firefox app after installation (bad!).

Comment 7

[Andrew Schultz]

Attachment: updated patch (checked in)

I'll check this in
(xuldoc.xpt and xultmpl.xpt were actually already there... dunno why we both missed them before)

Comment 8

[Andrew Schultz]

OK, the linux installer build works ok now, but only if run once by the owner of the files.  The chrome/app-chrome.manifest file needs to be generated (in the app directory), which happens when starting the app or when running "seamonkey -register".  So we really need a separate config.ini so that it can run seamonkey -register.

Comment 9

[Mark Banner (:standard8)]

(In reply to comment #8)
> So we really need a separate config.ini so that it can
> run seamonkey -register.
> 
A separate config.it/ini sounds reasonable. We could put it in /suite/installer/unix/. That just leaves the matter of how to switch between the two. I think adding an action to copy the relevant config.it into $objdir/somewhere and then generating it from there into config.ini might be best, though we'll have to change the perl files to accomodate that I think.

Comment 10

[Mark Banner (:standard8)]

Attachment: Fix the unix installer registration process (checked in)

This patch fixes the unix based registration process in the installer to use -register. As doing this requires two config.it files for us until we switch, I'm proposing we just insert the new config.it file as a new file rather than a copy. The new config.it file only differs from the old by the post-install run options.

Comment 11

[Andrew Schultz]

Comment on attachment 227091 [details] [diff] [review]
Fix the unix installer registration process (checked in)

> # Make sure there are at least six arguments
>-if(@ARGV < 6)
>+if(@ARGV < 7)

seven!

> {
>-  die "usage: $0 <default version> <URL path> <staging path> <dist install path> <app name> <app display name>
>+  die "usage: $0 <default version> <URL path> <staging path> <dist install path> <app name> <app display name> <config it location>

config.it
      ^

Comment 12

[Andrew Schultz]

Attachment: fix tinderbox bustage

The config.it location patch broke tinderboxen packaging scripts because the path has a "." and makecfgini.pl assumes the first "." is the one it wants and chops the rest off.  Previously, the config.it location was just "config.it".

I'll commit this shortly as a bustage fix so we have working installers, but I'm happy to fix it up if my perl-fu is lacking.

Comment 13

[Mark Banner (:standard8)]

(In reply to comment #12)
> Created an attachment (id=227350) [edit]
> fix tinderbox bustage
> 
> The config.it location patch broke tinderboxen packaging scripts because the
> path has a "." and makecfgini.pl assumes the first "." is the one it wants and
> chops the rest off.  Previously, the config.it location was just "config.it".

Weird, I thought I had checked that and came to the conclusion that it was working alright. Oh well.

Comment 14

[Mark Banner (:standard8)]

Attachment: Add missing help.manifest to unix installer.

I guess this is fallout from the help moving, I just noticed we're missing the help.manifest.

Comment 15

[Mark Banner (:standard8)]

Attachment: Add missing items to windows installer part 1 v1

This adds most of the missing packages that we need for suiterunner builds to the windows installer. DOMI still won't work, but we'll at least be capable of the same installation level as the unix installer for the time being.

I'd really like someone to test this and compare an installed directory structure to a zip one on windows before I request reviews though.

Comment 16

[Mark Banner (:standard8)]

(In reply to comment #15)
> I'd really like someone to test this and compare an installed directory
> structure to a zip one on windows before I request reviews though.

Note: the registration process on windows won't work properly just yet - we need to modify something to call seamonkey -register for that to work (I haven't thought about that patch yet).

Comment 17

[Robert Kaiser]

(In reply to comment #14)
> I guess this is fallout from the help moving, I just noticed we're missing the
> help.manifest.

Umm, we shouldn't use help.manifest (and help.jar) any more once we've fixed bug 344243 and are using toolkit help viewer instead of our own, so basically, this file is only of temporary existance in suiterunner...

Comment 18

[Mark Banner (:standard8)]

Attachment: Add missing items to os2 installer part 1 v1 (checked in)

This adds the new components/items for SeaMonkey with MOZ_XUL_APP set to the os2 installer packaging list (and incorporates the os2 fix for bug 349159). I haven't tested these as I don't have os2, but the additions list is the same as per the unix & windows patches on this bug.

Comment 19

[Mike Kaply [:mkaply]]

Comment on attachment 234427 [details] [diff] [review]
Add missing items to os2 installer part 1 v1 (checked in)

are there files that went away that ned to be deleted as part of the install.js stuff?

Comment 20

[Mark Banner (:standard8)]

(In reply to comment #19)
> (From update of attachment 234427 [details] [diff] [review] [edit])
> are there files that went away that ned to be deleted as part of the install.js
> stuff?

I'm not sure waht you mean be the "install.js stuff"?

Comment 21

[Mike Kaply [:mkaply]]

(In reply to comment #20)
> (In reply to comment #19)
> > (From update of attachment 234427 [details] [diff] [review] [edit] [edit])
> > are there files that went away that ned to be deleted as part of the install.js
> > stuff?
> 
> I'm not sure waht you mean be the "install.js stuff"?
> 

http://lxr.mozilla.org/seamonkey/source/xpinstall/packager/windows/browser.jst#375

Comment 22

[Mark Banner (:standard8)]

(In reply to comment #21)
> (In reply to comment #20)
> > (In reply to comment #19)
> > > (From update of attachment 234427 [details] [diff] [review] [edit] [edit] [edit])
> > > are there files that went away that ned to be deleted as part of the install.js
> > > stuff?
> > 
> > I'm not sure waht you mean be the "install.js stuff"?
> > 
> 
> http://lxr.mozilla.org/seamonkey/source/xpinstall/packager/windows/browser.jst#375
> 

Thanks, there will be some redundant packages, but until we throw the switch on trunk formally, I don't want to add them into the removal lists as that'll break the current trunk xpfe builds - so I've filed bug 349295 to remind us once we've switched that we need to check the lists.

Comment 23

[Mark Banner (:standard8)]

I'm putting this over to helpwanted - its just the installation of DOMI that needs sorting out. I haven't figured out how to do this, as I'm concentrating on other areas.

http://wiki.mozilla.org/ChatZilla:Suiterunner may be of interest also.

Comment 24

[Robert Kaiser]

The xpinstall-based installers are probably being killed from trunk completely very soon now, and for Windows we have the NSIS installer anyways, see bug 351917

Comment 25

[Mark Banner (:standard8)]

Comment on attachment 227350 [details] [diff] [review]
fix tinderbox bustage

This never got committed afaict. However, given that all our installers are running fine and we've shipped SM 2. I don't think this is necessary any longer - if it is, then we should move it to a separate bug.