Comment # 21
on bug 10737
from Guy Harris
(In reply to Jeff Morriss from comment #20)
> > > Sorry, my point was: what if the user installs us someplace *other than*
> > > /usr or /usr/local ?
> >
> > Then they have to figure out how to make it work. Expecting everything to
> > Just Work if you start doing things such as passing in --prefix= options to
> > the configure script is unreasonable.
>
> Well, it's been my experience that it's fairly common. I know after I
> reworked the RPM stuff I got a number of complaints about stuff not working
> when installed in some weird (not /usr, not /usr/local, not /opt) locations.
Then I hope they have fun tweaking various path-specifying environment
variables.
> > > (Though my experience thus far has been that /usr/local
> > > doesn't Just Work but maybe I'm still doing something wrong.)
> >
> > Either you or your desktop are doing something wrong, yes.
>
> Interestingly, it now it seems to be working better. But I'm on a different
> computer now with a different (older) version of Fedora.
Testing it on my Ubuntu 14.10 VM, once I ran all the damn post-install commands
(including ldconfig, sigh) and rebooted (just in case there was something I
missed) it worked fine with everything under /usr/local (although, this being
Ubuntu, there was no "application menu" to check; maybe I'll try it in my FC16
VM, or maybe chew up more "disk" space with a newer Fedora and try that).
> Predictably when
> installing in /opt virtually nothing (related to desktop integration) works.
And the fd.o people seem to be *so* interested in making that work better. :-(
I guess if people find the prospect of a path variable that includes everything
under /opt frightening, the alternative mentioned in one of the threads, namely
installing everything in the package under /opt but putting symlinks to them in
all the appropriate directories under /usr/local, so that code that searches
only in the directories under /usr and /usr/local still finds them, is the
least bad alternative (that's similar to what we and Xcode do on OS X, as per
the above).
But, as indicated, I don't care all that much about "./configure
--prefix={something other than /usr, /usr/local, or $HOME}; make; sudo make
install" Just Working without making sure *all* the appropriate path
environment variables refer to the target directory. It may be unfortunate
that you need to tweak PATH *and* MANPATH *and* possibly LD_LIBRARY_PATH *and*
XDG_WHATEVER_WHATEVER and so on, but that's UN*X breakage, not Wireshark
breakage.
> I agree in principle with a lot of what else you said but I'm worried that
> it used to work and now it doesn't.
Hopefully we can fix the cases where it doesn't work and it's the result of us
doing something non-standard, and the other cases will result in an increase in
backpressure to get distributions/desktop environments/etc. to search under
/usr/local in those cases where they should do so but are failing to do so.
> But then again I'm not sure how many
> people actually care about the desktop integration stuff.
The person who submitted this bug obviously does. :-)
You are receiving this mail because:
- You are watching all bug changes.