Closed Bug 283676 Opened 19 years ago Closed 6 years ago

change compressed (zip) build filelists to closely match installer builds

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: chase, Unassigned)

References

Details

We're currently making compressed builds out of a different set of files than
what feeds into the installer builds.  We need to create the compressed builds
using the same filelist we use for the installer builds to avoid nastiness like
what happened in bug 280084.
Are we going to make a manifest for mac, too? And are we going to do this for
1.8? If not, I would like to solve this "right" by not shipping anything to
dist/bin/* which we don't actually want to be shipped (I'll wiki about the
packaging plans for xulrunner apps).
Summary: change compressed build fileslists to closely match installer builds → change compressed build filelists to closely match installer builds
We can't do xpt merging for normal developers (unless we want them to have to
make in a second directory after local rebuilds), but we do want to do it for
what we ship -- including the zip builds, for which it's not currently done. 
That's the issue that caused bug 280084.
we want to stop shipping zipped and tarball builds. it's installers only from
here on out. should I file a different bug for stopping delivery of the
compressed builds for releases?
We should still fix this for nightlies.

I don't think there needs to be a bug for releases, since we need to just not
ship those files.  We still want the build process to generate them, since we
want them for nightlies.
Asa, I agree wholeheartedly for Windows, but on mac the "tarball-ish" DMG builds
are the platform standard. On *nix have we really considered the ramifications
of only shipping installers? The *nix installer code sucks, and a package that
was installed-by-makefile or RPMs are much closer to reality than an installer
(which would have to be run as root to be useful).
bsmedberg: can we use the FINAL_TARGET stuff to make sure that we only get
linked xpts in the zip-packaged area?

Only shipping the installer on Unix would, indeed, require a lot of additional
work to the installer, foremost in my mind removing its frightening tendency to
launch the browser (as root, oft).  Relying wholly on the installers on any
platform makes me nervous, since the installer code has been so woefully
underowned for as long as I can remember.  (Unless we make developers run the
installer or some command-line variant of it as part of their build cycle, I
fear we're going to suffer mightily for shipping something different from our
most-tested configuration.)
The FINAL_TARGET stuff by itself would not solve the linked-xpt problem. A
dynamically-generated XPT manifest might...
Is this wanted just because, or is ther a reason? For years, it's been very
handy for automated build fetching and testing to use zips.
PS: I'm referring to Win32 zips.
(In reply to comment #3)
> we want to stop shipping zipped and tarball builds. it's installers only from
> here on out. should I file a different bug for stopping delivery of the
> compressed builds for releases?

How is that going to end up working out on *nix and Macintosh?  Do we even have
a working installer for Macs, and I know from personal experience the installer
on *nix sucks hardcore.  I could see that working on Windows, with the MSI
installer, but anything besides that just doesn't look like it would work, at
least not right now.
Re comment 8, my reading of dbaron in comment 4 is that nightlies on all
platforms are still going to have the zip/tar/dmg builds available. At least I
hope that comment 3 is not suggesting that zip/tar/dmg builds are eliminated for
nightlies as well. That would really suck for nightly testers.
On Unix, as shaver said, we're nowhere near being able to rely on the installer.

Automatic build fetching for Windows I'm not so concerned with since Chase fixed
silent install, so we can in theory specify the options we want from the command
line in whatever scripts QA people use.  I rely on cygwin unzip as it is, but
that's a nasty dependency.  It'd be nice to make something viable for someone to
just use for a batch file process.

And of course, using the installer daily wouldn't be that bad for hammering out
kinks.
*** Bug 287499 has been marked as a duplicate of this bug. ***
*** Bug 287499 has been marked as a duplicate of this bug. ***
*** Bug 287499 has been marked as a duplicate of this bug. ***
Can someone please enumerate the differences here?  Obviously I could do an
install and compare the two, but it would be more accurate for someone who knows
the build system to tell us what the differences are.
Blocks: 287499
Shouldn't this wait until these bugs are all fixed?

Bug 281235
Bug 247884
Bug 229343
Bug 234680
Bug 245392
Depends on: 229343, 234680, 245392, 247884, 281235
um..installer bugs have nothing to do with this
No longer depends on: 229343, 234680, 245392, 247884, 281235
(In reply to comment #18)
> um..installer bugs have nothing to do with this

I thought this bug was going to require use of the installer. These bugs are
ones in the installer which should be fixed before it should be required to use it.
No, that's not what this bug is about.  It's about making zip builds contain the
same files as installer builds.
Given that this bug is now shown as a duplicate of 287499, its resolution should
also resolve that bug.  So fixing it should make it safe to re-introduce zipped
releases for Windows along with the .msi ones, as for reasons expressed
elsewhere many people need these.

To achieve this, it will be necessary to test that installing Zipped over
Installed updates, and vice versa, both work OK.  While the bug description only
mentions compressed builds, fixing the underlying problem may need some change
in the Installer scripts too?
Mass reassign of open bugs for chase@mozilla.org to build@mozilla-org.bugs.
Assignee: chase → build
(In reply to comment #21)
> Given that this bug is now shown as a duplicate of 287499, its resolution
> should also resolve that bug.  So fixing it should make it safe to
> re-introduce zipped releases for Windows along with the .msi ones, as for
> reasons expressed elsewhere many people need these.

It's been over a year since the last post. Is there still any chance the zipfile and installer versions will get unified or is there more chance of `wontfix'ing this bug?

> To achieve this, it will be necessary to test that installing Zipped over
> Installed updates, and vice versa, both work OK. {snip}

Well, I had this thought a year ago already but didn't post it then because the overall atmosphere seemed pretty "hot" (especially in bug #287499). Since the things seem to have calmed down as the time went on, I'll share it now:

If I understand (and recall) the main reason (per rationale in bug #287499, comment #12) for dropping the zipfile builds was the difference between zipfile and installer builds which caused huge problems when the updates were installed over the zipfile build. Well, I hope to not cause any more flame wars when I say the core of the problem seems quite invalid: I guess many users who prefer zipfile builds because they didn't like to run the installer (for whatever reason), would probably dislike the automated updates functionality as well.

I'm far from believing anything will change because of this (or at all), but it would be nice to see any comments on this thought.

It would also be great to see this bug closed (regardless of the final outcome) or any signs of progress show.

This is FIXED for unix/windows, and NEW for mac.
QA Contact: bryner → build.config
Reassigning to build.config@firefox.bugs and resetting the platform to correctly reflect Mac-only.
Assignee: build → build.config
OS: All → Mac OS X
Hardware: PC → Macintosh
Assignee: build.config → nobody
OS: Mac OS X → All
Hardware: Macintosh → All
Summary: change compressed build filelists to closely match installer builds → change compressed (zip) build filelists to closely match installer builds
triaging, old bug n/a now
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Component: Build Config → General
Product: Firefox → Firefox Build System
You need to log in before you can comment on or make changes to this bug.