[bugzilla-daemon@xxxxxxxxxxxxx]

Comment # 19 on bug 10737 from Guy Harris

(In reply to Jeff Morriss from comment #18) 
> When doing "make install" I could see that.  But when someone installs a
> package built by someone else my expectation would be that it Just Works.

It's "someone else"s job to make it Just Work.  It's not our job.

> I guess the question then becomes: do packages built using our packaging
> stuff Just Work?

>From a quick look, they appear to install under /usr, so they should Just Work;
they appear to be set up for OS-distributor packages rather than third-party
packages.

> 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.

> (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.

> https://code.wireshark.org/review/5600 gets RPM builds working again though
> right now non-/usr prefixes still don't (completely) work.

"non-/usr" as in "/usr/local" or "non-/usr" as in "/opt"?

The current FHS says, of /usr/local:

   
http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRLOCALLOCALHIERARCHY

"The /usr/local hierarchy is for use by the system administrator when
installing software locally. It needs to be safe from being overwritten when
the system software is updated. It may be used for programs and data that are
shareable amongst a group of hosts, but not found in /usr.

Locally installed software must be placed within /usr/local rather than /usr
unless it is being installed to replace or upgrade software in /usr."

and says of /opt:

   
http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES

"Programs to be invoked by users must be located in the directory
/opt/<package>/bin or under the /opt/<provider> hierarchy. If the package
includes UNIX manual pages, they must be located in /opt/<package>/share/man or
under the /opt/<provider> hierarchy, and the same substructure as
/usr/share/man must be used."

and

"Generally, all data required to support a package on a system must be present
within /opt/<package>, including files intended to be copied into
/etc/opt/<package> and /var/opt/<package> as well as reserved directories in
/opt."

although it doesn't say anything specific about icons, .desktop files, etc..  I
would personally lean towards counting those files as "data required to support
a package", in the sense that they make the package fit in with the desktop
environment as a whole.

The intent of /opt - which dates back to System V, in an era when the goal was
to support binary packages of commercial software - was, I think, to allow
third-party packaged applications to be self-contained, rather than throwing
files all over the file system.  Given that, what desktop environments *should*
do is scan subdirectories of /opt to find application icons, .desktop files,
etc..

As this message on the fd.o xdg mailing list indicates:

    http://lists.freedesktop.org/archives/xdg/2006-February/006101.html

if something gets installed under /opt, a *number* of environment variables,
including Good Old $PATH, need to be tweaked.  This is the downside of the /opt
model - and, as OS X's /Applications is pretty much the same model, it has the
same issue (which, for example, is why we install a pile of scripts in
/usr/local/bin for the command-line tools in Wireshark, and why at least some
versions of Xcode did similar things for the compiler tools).

And, yes, it *is* acknowledged as a downside:

    http://lists.freedesktop.org/archives/xdg/2006-February/006123.html

although it's not an XDG problem, it's arguably a *UN*X* problem, given that
stuff such as PATH, MANPATH, etc. that have nothing to do with XDG are
involved.  (Environment variables are showing their age - 1979 called, it wants
its user configuration knob solution back. :-))

Sadly, I don't see that getting fixed as long as we get:

    http://lists.freedesktop.org/archives/xdg/2006-February/006126.html

"OH NOES YOUR PATH WILL GET LONG!!!!!111ONE!!!!!" as a response.  Don't like
long paths, *GET RID OF THE WHOLE /opt THING AND HAVE ALL THIRD-PARTY STUFF
TOSSED UNDER /usr/local/... OR UNDER /opt/{bin,lib,share,etc.} RATHER THAN
BEING SELF-CONTAINED*.  *You don't get to have your cake and eat it too*; you
either get self-contained application packages and a lot of path tweaking or
extra stuff added to all path-searching code to search in the packages, or you
get a simple path not needing much tweaking at the expense of all your app
binaries, libraries, frameworks, and "resources" (icon files, desktop files,
plists, etc.) dumped into a small number of directories.

And I don't see OS X changing from the /Application model even if the rest of
the UN*X world gets rid of /opt.

So, I see several flavors of software installation.

The first is "./configure; make; make install", and the CMake equivalent.  The
use cases I see for that are:

    1) your platform doesn't provide a binary package for the software;

    2) your platform does, but it's out of date (cf. many Linux distribution -
I'm looking at *you*, CentOS and the bazillions of people with CentOS 6.5 who
get 1.8 from your repository and complain about it or about trying to get a
newer version working);

    3) you don't trust binary packages (but either trust our source packages -
and your compiler :-) - or audit the source first).

("I'm doing development" is probably a sign that you should be building from
Git - even if you're developing a plugin for 1.12, say, it might be easier or,
at least, no harder to do that from Git than from a tarball, as you'll probably
need all the auto* tools installed, etc..)

For that case, the right place to install is probably either the default,
/usr/local, or your home directory.

*That* should Just Work, which means it should, at minimum, install the icons,
desktop files, etc. *as part of "make install"*, and not require an additional
step, and perhaps should run any post-copying tools as well.

The second flavor is "OS-distributor package", as are provided by many Linux
distributions, *BSDs, Solaris, etc..  As far as I'm concerned, it's the job of
whoever makes that package to make things Just Work, even if that means
tweaking the source - Debian, for example, apply some of their own tweaks.  To
the extent that we can make that easier *without making "./configure; make;
make install" work any less well*, we should.

Those often install under /usr.  Are there any that install under /opt?

The third flavor is "third-party package".  I view those as having, as its use
cases:

    1) your platform doesn't provide a binary package for the software, and you
don't want to have to build from source;

    2) your platform does, but it's out of date (cf. many Linux distribution -
I'm looking at *you*, CentOS and the bazillions of people with CentOS 6.5 who
get 1.8 from your repository and complain about it or about trying to get a
newer version working), and you don't want to have to build from source.

We provide our own third-party packages for OS X and Windows, neither of which
have binary packages provided by the vendor.  We *don't* provide our own
third-party packages for any other platform; perhaps that would be useful for
the benefit of, for example, all the long-suffering CentOS 6.5 users, although
that might require Yet Another Buildbot.

For those, if we provide a third-party package, we should follow whatever
conventions are deemed appropriate for that platform to make things Just Work,
even if that means that we need to tweak things for that particular build.  If
somebody else provides the third-party package, it's up to them to make it Just
Work.

So:

    1) I'm willing to look at patches from people who want to make /opt
installations work, as long as they don't cause any reversion whatsoever for
this bug, and don't force the default /usr/local installation to put things
under /usr;

    2) I'm not particularly interested in spending time fixing /opt
installations myself;

    3) I think that if a /usr/local installation doesn't work, it's a problem
with the platform, not with wireshark.

---

      You are receiving this mail because:

• You are watching all bug changes.