263416 - Registering absolute program location paths with gconf is bad

Status: NEW

(Firefox :: Shell Integration, defect)

Description

[Christopher Aillon (sabbatical, not receiving bugmail)]

Solution:
- kill the tarball builds, and make everyone use either installer builds or
build their own from source.
- The xpinstaller could ln -s $installdir/$appname /usr/local/bin/$appname
- Same for make install
- Stop registering absolute paths.


Mostly filing so this isn't forgotten.  I have to run, but a quick summation of
why this is bad is that it really screws with distributions that rely on the
gconf stuff when updating.  Locations change with each major version update, and
causes complaints that the default browser is no longer there.

Comment 1

[Mike Shaver (:shaver emeritus)]

I'd certainly like to see a patch that lets us suppress the absolute path, and
use just the basename.

I don't think we should get rid of the tarball for the sake of GNOME integration
purity, because there are, in fact, people who use Firefox without GNOME, and
the tarball is much easier to contain and uninstall than an installer that puts
stuff in /usr/local/bin.  (It's also the only reasonable way to have multiple
versions installed, given what I've seen of the different RPMs that are produced.)

I'm not sure why locations would change with every major version update, though,
when they should be making /usr/bin/firefox work either way, no?

Again, this is a case where GNOME apps, in general and in my experience, do not
properly support being installed to an arbitrary location, while we go to some
lengths to make /path/to/where/ever/firefox Just Work.  If using absolute paths
is a violation of GNOME policy, though, then we should provide a mechanism to
suppress that.

FWIW, I can't find any documentation _anywhere_ that makes mention of
registration of absolute paths as being bad, for document handlers or URI
handlers or any other GNOME/gconf registration process.  I wish there was a way
to find out what the right thing to do was without post-facto bugs about why
what we chose sucks. =/

Comment 2

[Christopher Aillon (sabbatical, not receiving bugmail)]

I should have said registering the absolute program location is bad. 
/usr/bin/firefox is always in the same location.  The current situation
registers  e.g. /usr/lib/firefox-${FIREFOX_VERSION}/firefox-bin

Comment 3

[Mike Shaver (:shaver emeritus)]

That's not what I see.  I see "/opt/firefox/firefox" in my gconf key, not
"/opt/firefox/firefox-bin".  It does assume that the shell script is in the same
dir as the -bin, though, and finds it via that assumption.  Maybe that's the
problem for you?

Comment 4

[logan]

I'm not liking the sound of this.. :P    
                                                                               
                                       If forced, maybe the installer could be
improved a bit. The current setup of installer inside of a .tar.gz seems kindof
silly to me. Maybe it could be made a shar/whatever, like loki's installers.
Preferably something that'd take a --prefix and other options necessary for
zero/minimal interaction, as well as not requiring X (but could use if found).

http://www.megastep.org/makeself/