GRE installer needs to use new version key format

VERIFIED FIXED

Status

Core Graveyard
Installer: GRE
--
critical
VERIFIED FIXED
16 years ago
10 years ago

People

(Reporter: Sean Su, Assigned: Sean Su)

Tracking

({topembed+})

Trunk
x86
Windows 2000
topembed+
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt1])

Attachments

(3 attachments, 4 obsolete attachments)

(Assignee)

Description

16 years ago
The GRE installer currently registers itself as the following in the windows
regsitry:
  HKEY_LOCAL_MACHINE\Software\mozilla.org\GRE\[version]

where [version] is currently in the following format:
  1.3b

This [version] needs to be in the following new format:
  1.3b-[build id]

where [build id] is acquired from dist/include/nsBuildID.h.  '1.3b' should also
be automatically acquired from dist/include/mozilla-config.h, but not necessary
for this particular fix.
(Assignee)

Comment 1

16 years ago
I'm not sure if the install path should also include the build id as part of the
dir name:

  ie. [program files]\mozilla.org\GRE\1.3b-[build id]

I'll think about it some more...
Status: NEW → ASSIGNED

Comment 2

16 years ago
We need to make sure that both MfcEmbed and Mozilla are also updated to look for
the new registry key entry as part of fixing this bug.

Comment 3

16 years ago
Also, what will the build ID be, say, when we're done with a Mozilla milestone?

For ex, when 1.3 final is out the door, will there still be a build ID ?

Comment 4

16 years ago
i will fix both MFC embed and mozilla.

There will always be a build id.

Updated

16 years ago
Keywords: nsbeta1, topembed

Comment 5

16 years ago
Sean, should this buildID be included in the same field or create a new field
under the same key?  I'm thinking that buildID is hopefully too much granularity
for GRE clients (assuming we don't have to release GRE revisions every other
day), in case they do need to look at the buildID, then another field would be
fine, but parsing of all the extra info might be overkill in the general case.

Discussed at EDT: topembed+, please target accordingly.
Keywords: topembed → topembed+

Comment 6

16 years ago
I agree with Juan on having a separate build ID field under the same key. 

As we start freezing more of our embedding APIs and head towards a binary
distribution model, we can steer embeddors towards "certifying" their apps
against a released version of a GRE rather than against a specific build IDs etc.

Comment 7

16 years ago
the nsBuildID must be at the KEY level so that you have have more than one of
the same milestone GRE installed on your disk.

Comment 8

16 years ago
Should it then be added one layer deeper, rather than merged together with the
top-level version number?  It can still be a key that way.  Of course that would
mean that when faced with the question "which 1.3b GRE to use?" code should be
smart enough to either specify the actual buildID that it was certified/tested
against or the latest one which hopefully is the most stable available.

Comment 9

16 years ago
i don't think that will work.  
(Assignee)

Comment 10

15 years ago
Created attachment 113130 [details] [diff] [review]
patch v1.0

This patch will have GRE installer use a usergent value like '1.3b-[build id]'
for all the places in the windows registry needing a useragent value.

This means that it will now create:
  HKEY_LOCAL_MACHINE\Software\mozilla.org\GRE\1.3b-2003013001

where 2003013001 is the build id acquired from mozilla/config/nsBuildID.h.
(Assignee)

Comment 11

15 years ago
Created attachment 113131 [details] [diff] [review]
patch v1.1

updated the patch to look for nsBuildID.h in the dist/include dir instead of
directly from the mozilla/config dir.
Attachment #113130 - Attachment is obsolete: true
(Assignee)

Updated

15 years ago
Attachment #113131 - Flags: review?(sgehani)
(Assignee)

Comment 12

15 years ago
this bug needs to be fixed at the same time as a similar bug for mozilla. 
Mozilla needs to also look for the GRE version with the buildID, if not then
this patch will break mozilla.
(Assignee)

Updated

15 years ago
Attachment #113131 - Flags: superreview?(dveditz)

Comment 13

15 years ago
I'm concerned that we've still not clearly addressed Juan's points in #5 and #8
- a build ID is too granular for embeddors to write their apps to.

Also, could you please explain the rationale for including the build ID in the
top level reg key or whereever?

Comment 14

15 years ago
i think java and other things do something like this:

majorkey\
@default value=preferedsubkey

so:
[HKEY_LOCAL_MACHINE\Software\mozilla.org\GRE]
@="1.3b"
[HKEY_LOCAL_MACHINE\Software\mozilla.org\GRE\1.3b]
@="2003013001"
[HKEY_LOCAL_MACHINE\Software\mozilla.org\GRE\1.3b\2003013001]

is there something wrong with that approach?
(Assignee)

Comment 15

15 years ago
I think that the better fix would be bug 180383.  the installer code can already
detect if a GRE is compatible a the file version level (xpcom.dll to be exact).
 The browser code should be doing the same, not just looking at the windows
registry.
(Assignee)

Comment 16

15 years ago
Comment on attachment 113131 [details] [diff] [review]
patch v1.1

unrequesting the reviews until we figure out how we really want to resolve this
issue.
Attachment #113131 - Flags: superreview?(dveditz)
Attachment #113131 - Flags: review?(sgehani)

Comment 17

15 years ago
ssu - we need to land together on this one.  When you land, I must land at the
same time.  
(Assignee)

Comment 18

15 years ago
nsbeta1+ per samir.
Keywords: nsbeta1 → nsbeta1+
(Assignee)

Comment 19

15 years ago
oops, forgot adt1
Whiteboard: [adt1]
(Assignee)

Updated

15 years ago
Depends on: 195840
(Assignee)

Updated

15 years ago
Blocks: 195302
(Assignee)

Comment 20

15 years ago
Created attachment 116461 [details] [diff] [review]
patch v2.0 (ns tree)
Attachment #113131 - Attachment is obsolete: true
(Assignee)

Comment 21

15 years ago
Created attachment 116462 [details] [diff] [review]
patch v2.0 (moz tree)
(Assignee)

Comment 22

15 years ago
The latest patches will automatically have the installer build process parse the
following files for the appripriate build versions:
  [topsrcdir]\config\milestone.txt
  mozilla\config\nsBuildID.h

Once these patches have been checked in, the release nightly and milestone build
scripts will _no_longer_ be required to pass in build versions (the first 2
args) to the following makeall.pl scripts:
  ns\xpinstall\packager\windows\makeall.pl
  mozilla\xpinstall\packager\windows\makeall.pl
  mozilla\xpinstall\packager\win_gre\makeall.pl
  mozilla\xpinstall\packager\win_mfcembed\makeall.pl

These patches will not build generate the new GRE ID (ie: 1.4a_2003030610) right
now as required by this bug.  This is because bug 195840 has not been fixed yet.

So for now, everything will still work as before (with the exception of the
build process changes).  In order to enable the scripts to generate the required
new GRE ID, I'll attach another patch which will simply be a few lines change to
have it turned on.

All the changes in these patches are still required for the new GRE ID to be
properly generated and working with the installers.
(Assignee)

Updated

15 years ago
Attachment #116461 - Flags: superreview?(dveditz)
Attachment #116461 - Flags: review?(sgehani)
(Assignee)

Updated

15 years ago
Attachment #116462 - Flags: superreview?(dveditz)
Attachment #116462 - Flags: review?(sgehani)

Comment 23

15 years ago
Comment on attachment 116461 [details] [diff] [review]
patch v2.0 (ns tree)


>+$initEmptyValues          = 1;

Please comment about stuffing zeroes for non-existent ``parts'' of the version.

> # set environment vars for use by other .pl scripts called from this script.
>-if($versionParts[2] eq "0")
>+if($versionParts[2] eq "0" || $#versionParts eq 1)

We don't need the second comparison.

>+$ENV{WIZ_greUniqueID}          = StageUtils::GetGreSpecialID("$topsrcdir/../mozilla");

Please document what the special id is, where it comes from providing an
example or two. 

r=sgehani with those changes.
Attachment #116461 - Flags: review?(sgehani) → review+

Comment 24

15 years ago
Comment on attachment 116462 [details] [diff] [review]
patch v2.0 (moz tree)


>+# GetGreFileVersion()
>+#   To build GRE's file version as follows:
>+#     * Use mozilla's milestone version for 1st 2 numbers of version x.x.x.x.
>+#     * Strip out any non numerical chars from mozilla's milestone version.
>+#     * Get the y2k ID from mozilla/config/nsBuildID.h.
>+#     * Split the y2k ID exactly in 2 equal parts and use them for the last
>+#       2 numbers of the version x.x.x.x.
>+#         ie: y2k: 2003030510
>+#             part1: 20030
>+#             part2: 30510

Please comment with a big XXX that this won't work for dates > 65536, e.g.,
20030 71608 (July 16, 2003 8am).  This is a problem and we need to file a bug
to solve it.

>+  $versionMilestone = `perl milestone.pl --topsrcdir $aDirConfigTopSrc`;

Should we execute this using perl routines rather than assuming the
interpreter's name as perl.exe?  I seem to recall some installation having the
``perl5'' interpreter name.  Maybe cls can comment?  Is this a moot issue?

r=sgehani with the above changes and changes to the above patch applied here as
well.
Attachment #116462 - Flags: review?(sgehani) → review+
(Assignee)

Comment 25

15 years ago
Created attachment 116496 [details] [diff] [review]
patch v2.1 (ns tree)

updated patch with sgehani suggested changes.
Attachment #116461 - Attachment is obsolete: true
it's probably "good enough" to distinguish by date, without having to go into
hour granularity (it's good enough for the User Agent, anyway). In that case the
date breaks into year and month/day parts that always fit in a short.

By default two dev builds on the same day will share a GRE, and the force GRE
install mechanism will ensure it's the most recent one. Given that the most
likely reason for two builds on the same day is a blocker re-spin that's
probably desired behavior.

The other thing you could try would be to chop off the "2" in 2003 and spit it 5
and 4 -- 00303 0510 in the example above. We won't roll over until the year 2656
and you get to keep hour granularity if people think it's important. (with the
downside of a harder-to-understand version number.)
(Assignee)

Comment 27

15 years ago
Created attachment 116497 [details] [diff] [review]
patch v2.1 (moz tree)

updated patch with sgehani suggested changes.
Attachment #116462 - Attachment is obsolete: true
(Assignee)

Comment 28

15 years ago
Created attachment 116499 [details] [diff] [review]
patch v1.0 (moz tree)

This patch can only be checked in _after_ patches v2.1 have been checked in. 
This patch will simply switch the build scripts from using the simple
milestone.txt version (eg: 1.4a) to using a new define (GRE_BUILD_ID in
nsBuildID.h) that cls is almost done with, which would then return an ID of
whatever GRE_BUILD_ID is set to (should be something like '1.4a_2003030610').
(Assignee)

Updated

15 years ago
Attachment #116461 - Flags: superreview?(dveditz)
(Assignee)

Updated

15 years ago
Attachment #116462 - Flags: superreview?(dveditz)
(Assignee)

Updated

15 years ago
Attachment #116496 - Flags: superreview?(dveditz)
(Assignee)

Updated

15 years ago
Attachment #116497 - Flags: superreview?(dveditz)
Comment on attachment 116499 [details] [diff] [review]
patch v1.0 (moz tree)

sr=dveditz
Attachment #116499 - Flags: superreview+
Comment on attachment 116496 [details] [diff] [review]
patch v2.1 (ns tree)

>-Parameter=-mmi -ma -app "$ProductName$" -app_path "[SETUP PATH]\$MainExeFile$"
>+Parameter=-mmi -ma -app "$ProductName$ $UserAgent$" -app_path "[SETUP PATH]\$MainExeFile$"

Should it be $ProductNameInternal$? Change if it needs it before checking in

sr=dveditz
Attachment #116496 - Flags: superreview?(dveditz) → superreview+
Comment on attachment 116497 [details] [diff] [review]
patch v2.1 (moz tree)

>Index: packager/windows/config.it
>===================================================================
>+Parameter=-mmi -ma -app "$ProductName$ $UserAgent$" -app_path "[SETUP PATH]\$MainExeFile$"

$ProductNameInternal$ here too for consistency.

sr=dveditz
Attachment #116497 - Flags: superreview?(dveditz) → superreview+
(Assignee)

Comment 32

15 years ago
patches v2.1 (ns and moz) have been checked in.

Leaf, please update the nightly build scripts to not pass the version numbers
(the 1st 2 params) to any of the makeall.pl files.  They are no longer required.

patch v1.0 (moz tree) has not been checked in.  waiting on others before
flipping the switch.
(Assignee)

Comment 33

15 years ago
patch v1.0 (moz tree) checked in.  Code is now enabled.  marking this bug fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 34

15 years ago
Not sure if this is the right bug, but comment 2 made check my \COMMON FILES\
folder to see a whole load of mozilla.org\GRE\ folders with different build
numbers. 

Just a side effect for people that don't use uninstall before installing new builds.

Comment 35

15 years ago
Patrick: I just posted my scenario in n.p.m.general alluding to the fact that I
ran out of disk space when installing the latest nightly. My /common
files/mozilla.org/GRE/ was 138 megs !!!!

Comment 37

15 years ago
This is verified - the above bug addresses the installer logic bug to remove
prior GRE installationsref counted to zero.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.