[Portland] UNIX (SVr4) package compatibility

[Joseph Kowalski]

I'm jumping in very late here, so I apologize if these topics have already
been covered.  I tried to poke around the mail archives for related
discussions.  I found some related issues, but nothing quite the same.

First, at the moment, I'm only addressing the "desktop integration"
functions being provided.  Its perhaps easiest to think in terms of
an example such as xdg-desktop and then see how any conclusions generalize
from there.  (If its easiest to answer any of this by pointing at an
archived thread, please do so.)

At a very high level, I'm a bit lost to what significant advantage utilities
such as xdg-desktop offers over simply relying on the freedesktop.org
Desktop Menu Specification and Desktop Entry Specification.

Well, actually it does clearly provide one thing: It circumvents any issues
caused by $XDG_CONFIG_DIRS, $XDG_DATA_DIRS and others not be consistent
across implementations.  This is a very valuable function, but I think it
could be more simply addressed by a single, simple utility along the lines
of the POSIX utility getconf which provides a simple and uniform way to get
similar system configuration information.

Stretching my mind a bit, I can imagine perceived benefits from xdg-desktop
"mucking" with the desktop file as it goes by.  To my experience, ISVs don't
like this because they don't like fielding bugs they don't have control
over.

Why mention these high level concerns in mail with the Subject: line
"UNIX (SVr4) package compatibility"?  Because the proposed interfaces
won't work well with UNIX packages, while a simpler solution would.
Gnome is a serious part of Solaris UNIX.

The issue is that UNIX packages keep a database (the "contents" file)
which allows multiple packages to claim "ownership" of a file.  In the
case of regular files, this must be handled very carefully to get a
quality result (editable files), but it can be done.  A more obvious
example is a directory being "owned" by multiple packages which allows
a directory to automatically be removed at last reference.

To make this work, the preinstall script needs to know the full path
to the file/directory so that it can use the installf(1M) utility to
register its interest in the file.  The proposed xdg-desktop utility
purposely obscures this path.  There in lies the rub.

Even if one believes that supporting UNIX packages isn't of interest
(only rpm and debian bundles are mentioned), I think we want to be
careful not to hinder future development of registration features in
these installers.

I'm looking forward to hearing your thoughts on these topics (or pleas
for clarification, as I undoubtedly left something vague or ambiguous).

Thanks for your time and interest,

- Joseph Kowalski (joseph.kowalski at sun.com)

The expressed content of this mail is my own and does not
necessarily reflect the position of Sun Microsystems.