Closed Bug 592369 Opened 10 years ago Closed 10 years ago
Eliminate different file modified dates in omni
No description provided.
Comment on attachment 470840 [details] [diff] [review] Set all dates to 2010-01-01 h/o this doesn't work on osx
OSX requires a path for find
Upon further testing, it appears that windows requires -X to really be consistent in generating zips.
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.
Attachment #470880 - Flags: review?(benjamin) → review+
http://hg.mozilla.org/mozilla-central/rev/2242c9c14a63 Still needs a relbranch landing if applicable.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b6
Landed on GECKO20b5_20100831_RELBRANCH http://hg.mozilla.org/mozilla-central/rev/3c46705b7df0
(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.
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.
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.
(In reply to comment #10) > Once bug 313956 is fixed I _think_ we can back this out. Bug 313956 is fixed.
(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.
You need to log in before you can comment on or make changes to this bug.