[lsb-discuss] Installation directories

[Wichmann, Mats D]

>I think xdg-utils is the right approach here--namely, disallowing
>applications from modifying stuff outside of their /opt directory
>directly, but providing an "API" for doing things in a structured
>manner (create desktop icon, start service at boot time, etc.).

Yes, for those sorts of things it's okay, but that doesn't
cover the plugin question.  If I want to add a plugin to my web 
browser, where does it go?  Wait, which web browser:
Firefox from distro, Firefox from Mozilla.org, Iceweasel,
Gnuzilla, Opera, Konqueror, Epiphany, Galeon, SeaMonkey, Camino?
Should the plugin come from distro packaging? From the vendor?
Through a plugin registry site at the upstream for the browser,
as is provided for Firefox and relatives? Should the install
be a package-manager thing, or should it follow the model of 
"root around in places we know about and offer to drop it
straight in there?  As Donya touched on, whose responsibility is 
it if the underlying engine upgrades so that contained (plugins)
or containing code needs to be updated to match?

My concern is that we kind of have a story for a single-provider
software model, but not the multiple-provider model that's
becoming prevalent (in addition to web browsers, think media
frameworks, editors - particularly media editing like Gimp, etc.)

FYI, when this question comes up on the FHS list, it usually
morphs into a request to standardize user home directories
(what "dot" files/directories mean and if they even should exist)
and then fizzles because that's too big a nut for anyone to
take on.

>Speaking of that last bit, we should look at reviving lsbinstall as
>well for the non-desktop equivalent of xdg-utils. The right way
>to make this work is to create a canonical upstream
>version, similar to what freedesktop.org has done for xdg-utils.

>We can either promote the tool with the distros to try to get them
>to adopt it, or we could bundle it with the SDK to make it easy for
>apps to include in their postinst etc. scripts (we should do
>this for xdg-utils as well). The latter is probably the best option.

This is not a bad idea - although building a truly distro-
neutral version that anybody was free to bundle with their
app is a little trickier than our existing "proof-of-concept"
that worked on some given distro.  I worry that the presence
of xdg-utils might make it less compelling to have another
install-time tool out there...  We do, however, have prototype
code and specs for lsbinstall.