[Portland] UNIX (SVr4) package compatibility

[Joseph Kowalski]

> From: "Bastian, Waldo" <waldo.bastian at intel.com>
...
> 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.

Something like this might work, but it would actually be:

	cp $desktop_file $desktop_dir/$basefile
	if [ -n "$XDG_UTILS_INSTALL_HOOK" ] ; then
		$XDG_UTILS_INSTALL_HOOK $desktop_dir/$basefile
	fi

The file needs to be in place first (for a checksum, if nothing else), and
installf only takes the installed path.

[Note: there is also a removef to be used on removal (if desired)]

> 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

Experimentation would tell, but I think the less specified form of installf
could be used (the one that stops at "pathname" - the SYNOPSIS is a bit
confusing).

However, this seems like a rather "installf" specific solution.  Who knows
what parameter order or requirements future packaging systems would use. I
tend to doubt we would want to go this way.

> From: "Claes at work" <claesatwork at gmail.com>
...
> An alternative solution that I think would be simpler is if the utils
> included dry-run-options, and options to print the path of the files
> it creates / would create. It could then be called twice, first with
> dry-run to print the path, and then to actually do the stuff (If I
> understand the installf man page correctly, have never used it myself)

Something like this was my initial thought, but rather than "dryrun" a
PATH like list of the files installed would be easier to parse.

(Note, now transitioning to a generalized discussion, including RPMs on
Linux.)

My initial thought was that xdg-desktop would install the one true xdg
desktop file.  Upon examining the code, I see this was incorrect.  It
tries also to install in legacy locations, but only the "best known"
legacy locations - one each for Gnome and KDE.

Having just done this for a bunch of Linux distros, some of which are
very old, but still significant and supported by the product I work on,
I think this is woefully insufficient.  The distros had a habit of not
installing the desktop in the location that the desktop communities had
assumed (at least for Gnome).  SuSE seems to be particularly creative
and inconsistent across SuSE 7 through 10.

Rather than install in every possible location, I wrote my scripts to
attempt to decipher the location (and syntax) in use and to install only
that one and always install the xdg blessed location.  This may not be
the optimal model, but its the one I chose.  I assume that any upgrades
will be to a version which supports the xdg locations and not some other
legacy variant.

This leads to the $64,000 question of what is the intent of the legacy
support in xdg-desktop (and friends):

  1)	It is what it is, and will always only support the two legacy
	locations it currently supports.

  2)	It intends to take patches for support of more and more legacy
	configurations...
	
  2a)	and install all of them.
  
  2b)	and install the one (or KDE/Gnome pair) which appears to be in use.
  
  3)	Should drop attempts at legacy support.  After all, these utilities
	are unlikely to be on any distribution which doesn't support the
	xdg locations.

  4)	Something not quite any of the above...

My opinion/analysis of these are that #1 and #3 don't provide sufficient
benefit/utility over explicitly writing to the xdg specification.  After
all, the multiple 100's of lines of script, boil down to:

        for x in $xdg_dir $kde_dir $gnome_dir ; do
            mkdir -p $x
            eval 'cp $desktop_file $x/$basefile'$xdg_redirect_output
        done

where $xdg_dir comes from the environment and $kde_dir and $gnome_dir
are more-or-less hardwired.

After my experience with my product, my first response would be to welcome
something like #2 (actually #2b, because I have distaste for cluttering the
system with a bunch of unused files, but that's just me).  Having an eager 
community of contributors writing these heuristics sure beats me having
to do it, and I'd surely get broader platform support. However, my
second response is the realization that I won't be able to count on the
target system having these utilities (and I don't want a dependency on
a component I don't deliver).  Most likely, any system which had them
also would support the xdg specified locations. With the license terms, I
guess I could include them with my distribution, but I'd have to think about
this.  I'd be leery of altering they system in ways not directly related to
my product.

There also would be rather nasty support issues with option 2 (and
particularly 2b) - something for the would be maintainers of this to
consider.

Anyway, if perhaps the core group here could clarify which of the models
is being followed here, it would help focus the discussion.

> From: "Bastian, Waldo" <waldo.bastian at intel.com>
...
> 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.

Heading into a different topic here, but a couple of quick observations
about your proposal for xdg-desktop-menu:

   1)	I tend not to like complicating an interface just so it can deal
	with a legacy case (obviously a bit related to the above discussion
	on legacy support).  If such support is deemed necessary, perhaps
	two interfaces are warranted - a simple one which doesn't deal with
	this legacy case and a more complex one that does.

   2)	Nit: I think the proposed syntax is ambiguous:
   
	Xdg-desktop-menu install directory-file (desktop-file)+ 
[X-Vendor-Category]
	
	Example:
	
	xdg-desktop-menu install dir-file foo bar
	
	Is bar the category or the name of a file?  Would you limit the
	two to be in separate name spaces?
	
	Perhaps:
	
	xdg-desktop-menu install [-c X-Vendor-Category] dir-file (desktop-file)+

Thanks for listening,...

- Joseph Kowalski