RFE: tar.gz binary package name should include compiler name and version Steps to reproduce (on Solaris 2.7/SPARC): 1. Build Mozilla 2. cd xpinstall/packager/ 3. gmake Result: tarball in dist/ with the name "mozilla-sparc-sun-solaris2.7.tar.gz" Expected result: tarball in dist with the name "mozilla-sparc-sun-solaris2.7-forte7.tar.gz" (or "mozilla-sparc-sun-solaris2.7-gcc2.95.1.tar.gz" if Zilla was build with gcc 2.95.1) On Linux I would expect somethink like: "mozilla-i686-pc-linux-gnu-gcc.2.95.3.tar.gz" (or "mozilla-i686-pc-linux-gnu-gcc.3.2.tar.gz") instead of "mozilla-i686-pc-linux-gnu.tar.gz" This issue should help people a lot with the comiler-specific C++ name mangeling/ABI issues.

That information can be gleamed from about:buildconfig . I don't see a need to stick that in the default tarball name which can be easily changed. Most users don't care what compiler is used and those who do care should be reading the READMEs before downloading the tarball.

Christopher Seawood wrote: > That information can be gleamed from about:buildconfig People should be able to pick a matching build _before_ they download them. about:buildconfig assumes the build works on that platform - but what about (example!) a gcc2.95.x build where the platform has the wrong version of libCstd++ installed ? This build will never be able to start at all. Currently bugzilla is _full_ of these incompatibility issues and there should be a way to prevent this _before_ the users downloads the build. > Most users don't care what compiler is used They have to care at the moment when they install XPT packages with binary components or when they want to use JAVA. gcc2.95.x!=gcc3.0!=gcc3.2!=Sun Workshop/AIX xlc_r/etc. - each compiler produces C++-based binaries which are incompatible to C++-based binaries from other compilers. And I don't see how to get rid of the problems(=bugs in bugzilla, spam in news.mozilla.org) unless we extend the platform-spec string (e.g. "i686-pc-linux-gnu") to include the used compiler.

not installer -> build

You get rid of the problem by making sure that users read the documentation accompanying the tarballs, i.e. READMEs & release notes. If users aren't going to take that simple step to read the documentation, then I doubt renaming the tarballs (which you can happily do yourself before uploading) will help them.

Christopher Seawood wrote: > You get rid of the problem by making sure that users read the documentation > accompanying the tarballs, i.e. READMEs & release notes. There are no such "magic" up-to-date and maintained READMEs. Most builds don't even have READMEs or use dumb dummy READMEs, usually lacking lots of infos. The release notes are rotten in similar ways nor do they contain a full list of what is downloadable from ftp.mozilla.org. And the release notes only cover the release builds and not all the nightly builds in ftp.mozilla.org Sticking the info in READMEs in the binary tarballs is _too_late_ - at that time people may have wasted hours of downloading to fetch the wrong build (not all people have T1 or DSL lines). Identifiers like "i686-pc-linux-gnu" relect the hardware/OS/ABI being used at build time - however the info from "config.guess" is _incomplete_ for C++ applications - they should all use something like "i686-pc-linux-gnu-gcc2.95.2" to reflect which C++ ABI was used ...

Adding the compiler used to the tarball doesn't help when the tarball is renamed. There is more to "compatibility" than just the C++ ABI. What about the absence of gtk libs? Should we tack -nogtk onto the tarball? Or -no-zlib? -no-jpeg? Or on linux, the version of glibc is very important so add -glibc2.2 ? And -n32 for irix builds? And so on? That line of reasoning gets silly and out of hand really quickly. If the READMEs are missing or out-of-date, then submit a patch to have them updated. I'm not talking about sticking the readmes in the tarballs. That's what the distribution instructions state. IIRC, in each releases directory, there used to be README file which stated who distributed what tarballs and what was special about that tarball. IMO, each tarball should have its own README file, separate from the tarball, which should also be uploaded as <tarball>.README .

Christopher Seawood wrote: > Adding the compiler used to the tarball doesn't help when the tarball is > renamed. There is more to "compatibility" than just the C++ ABI. What about > the absence of gtk libs? Should we tack -nogtk onto the tarball? Or > -no-zlib? -no-jpeg? Or on linux, the version of glibc is very important so > add -glibc2.2 ? And -n32 for irix builds? And so on? That line of reasoning > gets silly and out of hand really quickly. Toolkit and the whole GTK+/JPEG/zlib stuff does not matter. I was thinking about the basic _incompatibilities_ caused for XPCOM modules, JAVA plugins, add-ons, plugins which use the new plugin API etc. etc. For some platforms we now have up to _four_ different compilers which are completely _incompatible_ to stuff compiled with other compilers and there _should_ be a way for the user to detect that. Using the READMEs is the wrong way - this "solution" failed in the past and will fail in the future. And most contributors don't even provide a README and is it unlikely to get all people to provide them unless a script gets written which removes all builds from ftp.mozilla.org which do not have a <tarball>.README for each <tarball>.tar.gz/<tarball>.zip/<tarball>.tar.bz2 etc.