[lsb-discuss] [Portland] UNIX (SVr4) package compatibility
waldo.bastian at intel.com
Wed Aug 9 15:59:04 PDT 2006
Installf , or at least something similar, sounds like a very useful
addition for DEB and RPM based systems as well.
(CC'ing lsb-discuss to make the LSB ppl aware of it)
I think it should be possible to make xdg-utils play nice with installf.
Would it work if the xdg-utils tools would call a hook before doing the
So e.g. having a XDG_UTILS_INSTALL_HOOK environment variable that would
be called before copying/linking/generating a file, so instead of
cp $desktop_file $desktop_dir/$basefile
the xdg-utils script would do
if [ -n "$XDG_UTILS_INSTALL_HOOK" ] ; then
cp $desktop_file $desktop_dir/$basefile
Would that work, or would that end up calling installf still too late in
The package would have to do something like
export XDG_UTILS_INSTALL_HOOK="installf $PKGINST"
before using the xdg-utils then.
May need a bit of tweaking to allow a bit more flexibility of how
arguments are passed to installf, e.g. something like:
export XDG_UTILS_INSTALL_HOOK="installf $PKGINST \$SOURCE \$DEST
I agree that "mucking" with files should be avoided if possible. I can
think of two situations where makes sense to have the tools "generate"
files on the fly though. One is where the system doesn't natively
supports the new format yet (e.g. KDE's mimetype support versus the XML
based mimetype descriptions of the XDG shared mimetype spec) The other
is for example my proposal for xdg-desktop-menu  where
xdg-desktop-menu would essentially generate the .menu file for sub-menus
by itself. I don't think generating the .menu file is a problem in that
case, but I'm very undecided on what to do with the "Category=" line in
the .desktop files.
Linux Client Architect - Client Linux Foundation Technology
Channel Platform Solutions Group
Intel Corporation - http://www.intel.com/opensource
OSDL DTL Tech Board Chairman
>From: portland-bounces at lists.freedesktop.org [mailto:portland-
>bounces at lists.freedesktop.org] On Behalf Of Joseph Kowalski
>Sent: Tuesday, August 08, 2006 2:28 PM
>To: portland at lists.freedesktop.org
>Subject: [Portland] UNIX (SVr4) package compatibility
>I'm jumping in very late here, so I apologize if these topics have
>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
>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
>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
>caused by $XDG_CONFIG_DIRS, $XDG_DATA_DIRS and others not be consistent
>across implementations. This is a very valuable function, but I think
>could be more simply addressed by a single, simple utility along the
>of the POSIX utility getconf which provides a simple and uniform way to
>similar system configuration information.
>Stretching my mind a bit, I can imagine perceived benefits from
>"mucking" with the desktop file as it goes by. To my experience, ISVs
>like this because they don't like fielding bugs they don't have control
>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
>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.
>Portland mailing list
>Portland at lists.freedesktop.org
More information about the lsb-discuss