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.

Earlier is better, but we can limp along without.

can you explain what you need?

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.

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?

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.

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

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

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

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.)

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

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.

+$fullProgName =~ /(.*)makejs\.pl$/; +if ($1){ + $pathName = $1; + } else { + $pathName = "."; +} The } else { line is overindented. Other than that, a=brendan@mozilla.org. /be

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

Unsetting missed milestones to aid triage queries.

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

have this (and its dependent) have bitrotted?

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