592369 - Eliminate different file modified dates in omni.jar

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Michael Wu [:mwu]]

Attachment: Set all dates to 2010-01-01

Comment 1

[Michael Wu [:mwu]]

Comment on attachment 470840 [details] [diff] [review]
Set all dates to 2010-01-01

h/o this doesn't work on osx

Comment 2

[Michael Wu [:mwu]]

Attachment: Set all dates to 2010-01-01, v2

OSX requires a path for find

Comment 3

[Michael Wu [:mwu]]

Attachment: Set all dates to 2010-01-01, use -X in zip, v3

Upon further testing, it appears that windows requires -X to really be consistent in generating zips.

Comment 4

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Comment on attachment 470880 [details] [diff] [review]
Set all dates to 2010-01-01, use -X in zip, v3

rs=me based on the previous version having r=bsmedberg.

Comment 5

[Michael Wu [:mwu]]

Attachment: hg patch ready patch

Comment 6

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

http://hg.mozilla.org/mozilla-central/rev/2242c9c14a63

Still needs a relbranch landing if applicable.

Comment 7

[Michael Wu [:mwu]]

Landed on GECKO20b5_20100831_RELBRANCH

http://hg.mozilla.org/mozilla-central/rev/3c46705b7df0

Comment 8

[Walter Meinl]

(In reply to comment #5)
> Created attachment 470995 [details] [diff] [review]
> hg patch ready patch

Was it intentional that dates of _all_ files in the package are set to 20100101, or shouldn't only the files packed up in omni.jar get the modified date. By now also the binaries and shared libraries of every shipped nightly come with this date, look e.g. in http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/09/2010-09-01-03-mozilla-central/firefox-4.0b6pre.en-US.linux-i686.tar.bz2
Thus, one cannot see looking at the dates in the unpacked directory when the nightly really was built.

Comment 9

[Mark Banner (:standard8)]

What was the point in doing this anyway? None of the comments I can see explain the reasoning behind this.

Also, are we going to have to bump the date to 20110101 next year? Or are we going to reference 2010 forever? If we're bumping the date, then surely we should automate that.

Comment 10

[[e-mail] (:bhearsum)]

The reason this was done was to get the file modifications consistent between Windows Installers and MARs, which is necessary to have partial updates continue to work.

Because MARs are generated differently, based on the ZIP, this was the best solution at the time. Once bug 313956 is fixed I _think_ we can back this out. I don't recall wanting it for any other reason.

Comment 11

[Steve Wendt]

(In reply to comment #10)
> Once bug 313956 is fixed I _think_ we can back this out.

Bug 313956 is fixed.

Comment 12

[Michael Wu [:mwu]]

(In reply to comment #11)
> (In reply to comment #10)
> > Once bug 313956 is fixed I _think_ we can back this out.
> 
> Bug 313956 is fixed.

Bug 600241 already landed and replaced this code with something else.