[Portland] xdg-utils - allowing for distro overrides

[Jeremy White]

If I bundle xdg-utils 1.0 in my application, a user
may eventually install my software on a system that has
xdg-utils 2.0 installed.  Further, presuming that xdg-utils 1.0
doesn't know how to handle their Grotnik 2000 Window Manager,
the user wants us to run xdg-utils 2.0, with it's full
support for Grotnik.

I see a variety of ways to address this problem, but don't
have a clear sense of which one is right.

The choices I see are as follows:

  1.  Use the PATH, luke

      Specify to ISVs that the proper way to invoke
      xdg-utils is to put their interal bin directory
      *last* in the path, and then to invoke the xdg-utils
      straight up, allowing local path precedence to
      take over.


  2.  Make it the users problem

      This is essentially the don't try to address it option;
      we just assume that users will have to manually override
      the scripts that the ISV provided.


  3.  Have the scripts be somewhat aware, and dynamically
      reroute to the newest version of xdg-utils

      This would imagine that the utilities would have
      a run time step to check for the location for the
      'best' version of xdg-utils, and then the code
      would automatically switch to that version.

      I imagine this in two flavors:

        A.  Add a xdg-locate script

            All ISVs would be required to
                  source <my-known-path-to-xdg-bin>/xdg-locate

            That script would guarantee that
            XDG_UTILS_PATH would be set to the 'best' version when it was done.

            Then ISVs would be recommended (not required, note)
            to invoke the xdg utilities with a command like this:

                $XDG_UTILS_PATH/xdg-open-url


        B.  Make each xdg script have a prolog that does essentially that

            This option takes the burden off the ISV; they
            just call
               <my-known-path-to-xdg-bin>/xdg-open-url
            and it dynamically figures out if it's the best flavor
            of xdg-open-url, and if not, calls the 'better' one.


My personal preference is for 3A, but that violates the KISS principle,
so I'm curious what other folks think; I also worry that ISVs won't
get it, and will never call xdg-locate, thereby make it a pointless
exercise.

I'm also a bit fond of 3B, but that *really* blows up KISS
(at least on the implementation side), and it suggests the need for
a '--really-use-my-version-no-matter-what-to-heck-with-grotnik'
flag on each xdg-util.

Thoughts?  Comments?  Silence means I get to implement it however I like <g>.

Cheers,

Jeremy