XP install package files need to be decentralized

RESOLVED WORKSFORME

Status

SeaMonkey
Installer
P2
normal
RESOLVED WORKSFORME
18 years ago
11 years ago

People

(Reporter: blizzard, Assigned: dveditz)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
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.
(Assignee)

Updated

18 years ago
Assignee: ssu → dveditz
Target Milestone: M16
(Assignee)

Comment 1

18 years ago
Earlier is better, but we can limp along without.
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 2

18 years ago
can you explain what you need?
Target Milestone: M16 → M18
(Assignee)

Comment 3

18 years ago
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.
Summary: XP install files need to be decentralized → XP install package files need to be decentralized

Comment 4

17 years ago
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?
(Assignee)

Comment 5

17 years ago
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

17 years ago
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
Keywords: patch

Comment 7

17 years ago
Created attachment 16154 [details] [diff] [review]
cleanup and optional output for makejs.pl

Updated

17 years ago
Blocks: 55106

Comment 8

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

Axel
(Assignee)

Comment 9

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

Comment 10

17 years ago
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

17 years ago
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

17 years ago
Created attachment 17520 [details] [diff] [review]
new patch, fixing call in srcdir

Comment 13

17 years ago
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

Comment 15

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

Axel
Keywords: patch
(Assignee)

Comment 16

17 years ago
Unsetting missed milestones to aid triage queries.
Target Milestone: M18 → ---
(Assignee)

Updated

17 years ago
Keywords: nsbeta1
Priority: P3 → P2
(Assignee)

Comment 17

17 years ago
Not given the bandwidth to deal with this right now...
Keywords: nsbeta1 → mozilla1.0, nsbeta1-

Updated

16 years ago
Keywords: nsbeta1

Updated

16 years ago
Keywords: nsbeta1-

Updated

16 years ago
Keywords: nsbeta1
Product: Browser → Seamonkey

Comment 18

12 years ago
have this (and its dependent) have bitrotted?
(Assignee)

Comment 19

11 years ago
There's now various mechanisms for doing this. Not quite what this originally envisioned but still workable for optional extensions during build time
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.