[Portland] UNIX (SVr4) package compatibility

[Bastian, Waldo]

Installf [1], 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
actual copying?

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
		$XDG_UTILS_INSTALL_HOOK $desktop_file
$desktop_dir/$basefile
	fi
	cp $desktop_file $desktop_dir/$basefile

Would that work, or would that end up calling installf still too late in
the process?

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
\$PERM"
and
	SOURCE=$desktop_file
	DEST=$desktop_dir/$basefile
	PERM=0644
	eval $XDG_UTILS_INSTALL_HOOK

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 [2] 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.

[1] http://www.scit.wlv.ac.uk/cgi-bin/mansec?1M+installf
[2]
http://lists.freedesktop.org/archives/portland/2006-August/000765.html

Waldo Bastian
Linux Client Architect - Client Linux Foundation Technology
Channel Platform Solutions Group
Intel Corporation - http://www.intel.com/opensource
OSDL DTL Tech Board Chairman

>-----Original Message-----
>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
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.
>
>_______________________________________________
>Portland mailing list
>Portland at lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/portland