Closed Bug 277066 Opened 20 years ago Closed 5 years ago

Toolkit apps need to provide .package (autopackage files) for different linux distro users

Categories

(Toolkit Graveyard :: Build Config, defect)

All
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: mozillabugs.3.maxchee, Unassigned)

References

Details

Attachments

(4 files, 2 obsolete files)

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/
OS: Windows ME → Linux
Hardware: PC → All
Version: unspecified → Trunk
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
> 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.
Assignee: mscott → nobody
Component: Installer → Build Config
Product: Thunderbird → Toolkit
QA Contact: build-config
Summary: Thunderbird needs to provide .package (autopackage files) for different linux distro users → Toolkit apps need to provide .package (autopackage files) for different linux distro users
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.
Attachment #289666 - Attachment is obsolete: true
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.
Attachment #289697 - Attachment is obsolete: true
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.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: