22062 - XP install package files need to be decentralized

Status: RESOLVED WORKSFORME

(SeaMonkey :: Installer, defect, P2)

Description

[Christopher Blizzard (:blizzard)]

The current setup for the XP install files need to be decentralized.  Right now
they are in a single place which makes it really hard to keep up to date and
it's really easy to deliver a broken build.

Comment 1

[Daniel Veditz [:dveditz]]

Earlier is better, but we can limp along without.

Comment 2

[Cathleen]

can you explain what you need?

Comment 3

[Daniel Veditz [:dveditz]]

He's talking about the package files (I think there is already another bug that 
covers this or something similar). If you build without Chatzilla for example, 
why should the copy program try to copy Chatzilla files in the main 
packages-<platform> list? This will be an especial problem if the release team 
ever flips the switch that makes missing files a fatal error rather than a 
warning.

A better system would be to have sections of the tree maintain their own 
package lists, and export them to a common place (say $(DIST)/install/packages) 
with names like mail.win, aim.win or whatever. Then the copying script would 
run over all the files that happened to be part of the build.

This could also be done for install script templates and final XPI creation. 
The config.ini generation could remain somewhat static since it represents a 
decision to ship a certain collection of items (and would be pretty difficult 
to generate given the potentially complex inter-dependencies)

This could be made "help wanted", it's not required for shipping Netscape 6 and 
I'm not likely to get to it soon. It does need to be done though.

Comment 4

[timeless]

At the risk of this bug being futured and helpwanted.

Leaf: Is there anyone who can provide more input, should this bug be given to 
cls?

Comment 5

[Daniel Veditz [:dveditz]]

If anyone wants to tackle this please talk to me, I've given it a lot of 
thought already that might form a good starting point (or at least someone time 
not having to go down blind alleys (-: ). Believe me, this is the highest 
priority for the XPInstall team as soon as we ship Netscape 6. We may even get 
to it prior to ship on the trunk once N6 has branched.

The XPInstall team desperately wants to get out of the "install writing" 
business and stick to the core engine, pushing the actual scripts into the 
various components of which there are only going to be more over time.

Comment 6

[Axel Hecht]

I will attach a patch to xpinstall/packager/unix/makejs.pl to 
1) remove alot of warnings, done by removin old windows text, and getting the
sub to the beginning
2) work on builddirs. The easiest way was to optionally have an output name
given. This is quite nice for generating install.js files, as the source can 
have any name now.

Open issues: not every perl is in /usr/bin. Is it safe to use env?

I can now use makejs.pl in non xpinstall Makefile.ins like this:

$(PERL) $(topsrcdir)/xpinstall/packager/unix/makejs.pl
$(srcdir)/transformiix.jst $(_T_VERSION) . install.js

Axel

Comment 7

[Axel Hecht]

Attachment: cleanup and optional output for makejs.pl

Comment 8

[Axel Hecht]

Dan,
could you review this patch? I think it's a good pleasure/risk ratio.

Axel

Comment 9

[Daniel Veditz [:dveditz]]

I'd like to defer to Sean and Samir on this one -- could you guys review the 
patch?

Comment 10

[Samir Gehani]

Axel,
The patch looks fine.  Please run deliver.pl with a srcdir build to make sure
the install script generation is still working.  (The release team uses
deliver.pl and hence makejs.pl.  Thanks.)

Comment 11

[Axel Hecht]

Hi Samir,
good idea. Found a bug :-(. I had to set the current path to "." for running
in srcdir.

New patch attached.

Axel

Comment 12

[Axel Hecht]

Attachment: new patch, fixing call in srcdir

Comment 13

[Samir Gehani]

Axel,
This looks fine.  If you have run deliver.pl to produce a successful installer
delivered to mozilla/installer/raw nthen r=sgehani.  Thanks for making teh
srcdir fix.

Comment 14

[Brendan Eich [:brendan]]

+$fullProgName     =~ /(.*)makejs\.pl$/;
+if ($1){
+  $pathName       = $1;
+  } else {
+  $pathName       = ".";
+}

The } else { line is overindented.

Other than that, a=[e-mail].

/be

Comment 15

[Axel Hecht]

did my homework, reread the keywords spec. Removing patch keyword, should have
been review.
Patch is checked in, bug stays open.

Axel

Comment 16

[Daniel Veditz [:dveditz]]

Unsetting missed milestones to aid triage queries.

Comment 17

[Daniel Veditz [:dveditz]]

Not given the bandwidth to deal with this right now...

Comment 18

[Wayne Mery (:wsmwk)]

have this (and its dependent) have bitrotted?

Comment 19

[Daniel Veditz [:dveditz]]

There's now various mechanisms for doing this. Not quite what this originally envisioned but still workable for optional extensions during build time