Since we are already providing MSI packages for windows, maybe we should also provide autopackage files for linux. The only problem before is that each distro uses different packaging mechanisms, but autopackage now solves the problem. According to its website, autopackage is a tool that "lets you create binary packages for Linux that will install on any distribution, can automatically resolve dependencies and can be installed using multiple front ends, for instance from the command line or from a graphical interface". With autopackage, users of any distros can install freshly released Firefox in a distro-compliant manner (unlike the installer). For more info., go to http://autopackage.org/

http://autopackage.org/faq.html#3_1 (this is a big problem) http://autopackage.org/faq.html#5_7 (mozilla.org products are c++) people who want native packaging can get firefox/tbird/etc from their distro vendor. Most include recent releases and push security fixes out as well.

(In reply to comment #1) > http://autopackage.org/faq.html#3_1 (this is a big problem) > http://autopackage.org/faq.html#5_7 (mozilla.org products are c++) > > people who want native packaging can get firefox/tbird/etc from their distro > vendor. Most include recent releases and push security fixes out as well. Of course, except people will need to wait a few months before the package maintainers can release a stable package. This is why I suggested the use of autopackage in the first: to allow early adopters to start using the latest alpha/beta/RC/release right away and uninstall without any ill effects. Lack of intergration with RPM is not a huge problem as long as the package can be uninstalled cleanly.

rpm on Red Hat/Fedora won't let you uninstall Mozilla unless you do it with --nodeps. Other things depend on the libraries being there. Sometimes they even depend on the right versions of the libraries being there, so it *is* a problem.

> For these reasons, we plan to add native package manager integration as a high > priority feature in the next major development cycle after 1.0. Therefore, it will be probably be viable by the time Firefox 1.5 is released. Besides, autopackage is not our only choice. We also have: Smart Package Manager (http://zorked.net/smart/doc/README.html#overview) OpenPKG (http://www.openpkg.org/flyer.html)

Smart Package Manager requires RPM 4.4 and pygtk-2.4 (Fedora Core 3). That's much too restrictive. OpenPKG focuses on source RPMs both would require the user to install additional software on their machine and configure it. I really doubt there's a magic bullet.

Can't we marge this bug and bug 277065 into "Switch our own linux installer to autopackage"? Autopackage seems to be cross-distro, nice, modern and easy to use installer, and our own installer is mostly unusable now :(

*** Bug 277065 has been marked as a duplicate of this bug. ***

> Autopackage seems to be cross-distro, nice, modern and easy to use installer, See my previous comments in this bug.

> http://autopackage.org/faq.html#3_1 (this is a big problem) I don't really understand why the "What's wrong with apt?" FAQ entry is a problem. > http://autopackage.org/faq.html#5_7 (mozilla.org products are c++) But does Mozilla use any *external* C++ libraries? Because that's what it's all about. For example, KDE apps get hit hard because they rely on many external C++ libraries. AbiWord does not, because it's only internally C++. If Mozilla is only internally C++ and doesn't use huge external C++ libraries, then providing an autopackage is entirely viable. And yes, you should view autopackage support as replacing the current Linux installer.

> I don't really understand why the "What's wrong with apt?" FAQ entry is a > problem. they've added to the document since I wrote that comment. It's 4.1 now: # If I install an autopackage, RPM won't know about it! see comment 3. For the C++ stuff, Mozilla binaries have generally linked against older libstdc++ so that they can used by everyone. So it does matter. However, the installer / tarballs aren't doing any better than autopackage would be able to do. The point is that autopackage isn't giving people what they expect from an RPM (a binary compiled for their system). The only way to do that is to /compile a binary for their system/. The package format is pretty irrelevant on this particular aspect. Beyond that, autopackage requires users to /execute/ the file they would download from us (if they don't already have autopackage). That's creepy. That not only installs our software, but autopackage's software as well and modifies their system files. Users shouldn't have to install 3rd party software to install Mozilla/Firefox/Thunderbird, etc. It also looks like half the advantage of autopackage is apbuild, which is designed to build more portable binaries (perhaps resolving issues like the C++ one mentioned above). AFAICT, we could just use apbuild without autopackage, although it seems to still be in development and would require non-trivial changes to the build system. http://autopackage.org/docs/devguide/ch07.html Practically speaking, if you think autopackage (or Smart Pakacage Manager or OpenPKG, etc) is the best thing since sliced bread, the best way to make this happen is to do the work. Attach a patch or contribute your builds to .mozilla.org http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.7.7/contrib/

> Beyond that, autopackage requires users to /execute/ the file they would > download from us (if they don't already have autopackage). The current Firefox/Thunderbird installer also has to be executed. I don't see why autopackage would be any worse? And if you want to, you can inspect the packages for malicious code. It's just a shell script that you can read in 'less'. > That not only installs our software, but autopackage's software as well and > *modifies their system files* Autopackage *does not* modify system files in any significant way. The only - I repeat: ONLY - modifications autopackage makes are: 1. bashrc/profile, to ensure that paths like $PREFIX/{bin,lib} are in $(LD_LIBRARY_)PATH and other variables. Actually, this is going to be changed: starting from 1.0.2, all those things are stored in a seperate file. The *only* modification made to bashrc will be exactly one line, and one line only: 'source /etc/autopackage/paths-bash' (or something along the lines of that). This way there will even be less "OMG they edited dot-bash-ar-see!" complaints. We've extensively tested all this stuff and I'm willing to jump into a vulcano if autopackage ever manages to screw up your bashrc. :) 2. /etc/ld.so.conf, to ensure that $PREFIX/lib is in the library search path (in this case, it won't touch $LD_LIBRARY_PATH). 3. /etc/man.conf, to ensure that installed man pages are found. Although I've yet to see an autopackage which installs man pages... And yeah, that's it. Your system files are not modified in any significant way that can possible screw things up. I guarantee you that your system will continue to work. We don't perform black magic on your system. > although it seems to still be in development and would require > non-trivial changes to the build system. CC=apgcc CXX=apg++ ./configure Non-trivial changes indeed. ;) And make sure you don't forget to build against older GTK headers to avoid dependancy on newer GTK symbols. Download the older gtk headers tarball on the website and see the readme.

> The current Firefox/Thunderbird installer also has to be executed. sure, but that's creepy too. :) I'm arguing that autopackage does not provide many of the benefits of RPMs. If autopackage is only incrementally better than the installer, then it's not worth the effort to switch. We could just switch to RPMs and let people use alien (http://kitenet.net/programs/alien/) or some such thing to convert to other distro formats (or use alien ourselves to generate the other formats). Scripts are also sometimes included with RPMs ({post,pre}{un}?install) but, the level of complexity of the autopackage shell script is going to have to be substantially more complex than the RPM scripts, which are generally trivial. > CC=apgcc CXX=apg++ ./configure > Non-trivial changes indeed. ;) ok. The mozilla build system sometimes does non-trivial things all on its own. Are apgcc and apg++ guaranteed to handle them all (ccache, for instance makes such a guarantee). > And yeah, that's it. Actually, I was assuming that somewhere .package files needed to be associated with the autopackage program. Or perhaps it uses #!/usr/bin/autopackage

[In reply to comment #12]: > Actually, I was assuming that somewhere .package files needed to be associated > with the autopackage program. Or perhaps it uses #!/usr/bin/autopackage After the initial install, .package files are assiociated with autopackage-frontend-gtk (GUI installer for Autopackage) [In reply to #10]: > Practically speaking, if you think autopackage (or Smart Pakacage Manager or > OpenPKG, etc) is the best thing since sliced bread, the best way to make this > happen is to do the work. Attach a patch or contribute your builds to > .mozilla.org I've attached an apspec file that will create an autopackage from the official binary. You can see the result here: http://www.wildgardenseed.com/Taj/autopackage/firefox-1.0.3.x86.package It won't blow your computer up, trust me. :) Please, just try it and see if you think it rocks or sucks. -- Taj

> We could just switch to RPMs and let people use alien But you'll get into trouble with things like dependancy names. For instance, GTK is called "gtk" on Fedora, "gtk2" on RedHat 8 (I think), "libgtk2" on Debian/Ubuntu, etc. On top of that, if you use Alien it's not guaranteed to install things like menus properly. One advantage autopackage has over alien and the current installer, is that it's able to integrate nicely with the desktop. Menus will show up, file associations will work, that kind of things. We provided functions to make doing that easy. The current installer and alien just copy some files around, but that doesn't guarantee that, for example, menu items will actually show up. And autopackage allows installing to the home folder. So if you're somehow afraid that autopackage will screw up your system, just install to the home folder and /usr will be left intact. This way you can play around with it all you want with no worries. > the level of complexity of the autopackage shell script is going to have to be > substantially more complex than the RPM scripts, which are generally trivial. Autopackage scripts are not complex at all. See also Taj's specfile. You just call "copyFiles SOURCE DESTINATION" to copy files, and call the install* series of functions for special file types. For example, binaries should be installed with installExe, .desktop files by installDesktop, libraries by installLib, etc. Not exactly rocket science. And our tools can make a sample specfile for you so you don't have to write the same things over and over. :) > Are apgcc and apg++ guaranteed to handle them all (ccache, for instance makes > such a guarantee). I can't really say "guaranteed", but I can say there are no known problems.

(In reply to comment #12) > If autopackage is only incrementally better than > the installer, then it's not worth the effort to switch. We could just switch > to RPMs and let people use alien (http://kitenet.net/programs/alien/) or some > such thing to convert to other distro formats (or use alien ourselves to > generate the other formats). I can't agree here. Autopackage seems to create a transparent layer between configuration and installation scripts and specific distribution enovirment. And I find it extremly usefull. RPM is a solution for some distros, while on the others it's extremly poor supported (Slack, Debian, Gentoo). Moving to autopackage should give us modern way to install our software on many linux ditributions. Another topic is that using autopackage we use the power of open source. Mozilla devs will not have to work on this to improve it. Autopackage guys will. And we will benefit of this. In the future using autopackage we hav a great chance that our installer will work on any freaky new distros out of box. RPM is not as handfull here.

ok, so I tried it, and it failed with a big ker-splat. apgcc failed to compile a single Mozilla source file and was much slower than gcc (it took a really long time to just to run configure). Is there somewhere else we could discuss this (newsgroup? n.p.m.xpinstall perhaps)? This bug isn't really the appropriate place to discuss the appropriateness of packaging formats.

Please subscribe to autopackage-dev@sunsite.dk (http://autopackage.org/community.html) and report this apgcc bug. We can also move further autopackage discussion to that list. And yes, apgcc is supposed to be slower than gcc because it's a wrapper around gcc. (This is why it's supposed to be used for the final build, not while developing.) But you can dramatically speed up apgcc by upgrading to the latest binutils (which supports ld --as-needed) and apbuild 1.9.0. Our built-in bogus dependancy stripper runs gcc twice to strip dependancies but obviously ld --as-needed as do it better and faster.

(In reply to comment #17) > ok, so I tried it, and it failed with a big ker-splat. apgcc failed to compile > a single Mozilla source file and was much slower than gcc (it took a really long > time to just to run configure). You don't really need to use apbuild for Firefox/Thunderbird as the MoFo already has a build system designed for binary portability up and running. Apbuild is designed mostly as a convenience for the majority of devs that don't have a dedicated build box.

On a user level, autopackage provides great possibilities for Linux. Installing an autopackage is much easier for prior Windows & Mac users to digest than the current package manager/repository system most distros use. People like being able to go to the official site for a program, download it and then install it, not digging around in some proprietary distro repository in hopes that someone has graciously included it for them to install. And then they have to hope that it's even somewhat up to date too. If more linux software was offered as an autopackage or something like it (both distro-neutral and user friendly) then it would probably be the thing that made Linux really take off with the average joe user. As Firefox and Thunderbird are just about the most well known open source projects (with users, not developers and sys admins), an official autopackage released by the Mozilla Foundation could really get the ball rolling for Linux in general. My other concern is the idea that RPMs are even remotely like AP. Here's an example, if you were a brand new Linux user using Ubuntu, what do you think would be easier to deal with? Installing an autopackage, or converting an RPM to a DPKG after figuring out how to install alien, and then crossing your fingers that even? Then again they could try installing via the current installer, or just unzipping a .tar.gz, but how would they ever uninstall it? Autopackage is THE most user friendly Linux installation method available, and not only that but it works with virtually any distro out there. As a developer what would you rather do? Make a RPM, DPKG, Ebuild, various other formats, and then a static tarball (read bloated) or just one Autopackage for them all at once? I think the answer's pretty simple. Furthermore, I think it's ridiculous for users to have to rely on their distro maintainers to package anything beyond the OS itself (counting core components, libaries, and desktop environment(s) in there too). Autopackage lets us get away from the usual, very limited system most Linux distros use and puts package distribution back in the hands of the actual application developers. Please seriously consider releasing an official .package in the future. Mozilla may not need it to be successful, but the rest of the Linux world could seriously benefit from it. Thank you.

Comment on attachment 201426 [details] .applications file to be moved upstream Not knowing much about .applications files, how do we register for multiple mime types, can we also register for file extenions, and/or is there a way to add extension->mimetype mappings (in particular .xul and .xpi).

(In reply to comment #23) > (From update of attachment 201426 [details] [edit]) > Not knowing much about .applications files, how do we register for multiple > mime types, can we also register for file extenions, and/or is there a way to > add extension->mimetype mappings (in particular .xul and .xpi). > The .applications files are for Gnome < 2.10. .applications files tell Gnome to open files of a certain MIME Type with Firefox. Gnome uses .keys files to associate file extentions with MIME Types. KDE uses .desktop files. And the new FreeDesktop.org standard uses XML files. In the Autopackage Packagers guide, we have a section on it: http://autopackage.sunsite.dk/docs/devguide/autopackage.html#mimetypes It would be great to have .keys and XML file associations upstream. Autopackage automatically generates KDE 3.x .desktop files from XML files.

*** Bug 329506 has been marked as a duplicate of this bug. ***

Hi, Will there be an autopackage for Firefox 3? Would be great!

If you write a patch to create such a thing, there might be...

Okay here it is. I created it with the CVS source. For creating a package it must be placed inside a folder called "autopackage" and then you call "makepackage" in the mozilla folder. Most of the Code is copied from Taj. Here is a package of firefox 3.0b2pre: http://watteimdocht.de/jan-nik/Mozilla%20Firefox%203.0.package

I did a little mistake, now the icon will be installed too.

It would be a lot easier to test this if it were in the form of a patch, and we could just run "make autopackage" the same way we run "make package", see http://lxr.mozilla.org/mozilla/source/browser/build.mk#57 and http://lxr.mozilla.org/mozilla/source/browser/installer/Makefile.in

I'm sorry i don't know enough about makefiles, maybe someone else can look into this.

Okay, i tried my best to create a patch. It's not the best way, because i really don't know much about automake.

Hi, is my patch okay? I really want to help providing an autopackage for firefox 3. :)

At the moment people are really busy with Firefox 3, and in the grand scheme of things this is fairly low-priority because, practically, the distribution mechanism for Linux software is distro repositories. It's a bit of a chicken-and-egg problem, but realistically even if an autopackage were available people wouldn't start massively downloading it. I'm all but certain this won't make Firefox 3. I asked around a touch about who could review, but unfortunately people are pretty busy. I'd suggest sitting on what you have for another month or so (or however long) until 3 is out and then make another stab at getting someone to review, because it's not going to happen for now.

Triaging old bugs, we will leave packaging up to the distros, closing.