However, the more I think about it, the more useless I see the
  desktop.mk file.  The reason is that ~95% of the packages wanting to
  install .desktop files, if not all, will simply do:

From the point of view of making it easy to add desktop file support,
having the variable/.mk is easier, since it takes care of USE_DIRS,
the install, and presumably you don't need the file in PLIST.
I view post-install targets as a sign of something being missing.

How would this interact with applications that already install desktop
files?  Just omit the variable?

  Therefore, I will rework desktopdb.mk in such a way that the packages
  only update the mime database iff desktop-file-utils is installed
  (similar to what I did in pkg_alternatives), and then make GNOME
  (nautilus, or whatever) explicitly depend on this tool to delay the
  dependency as much as possible.

So the invariant is that if desktop-file-utils is installed, then the
MIME type database is a correct summary of all desktop files that are
installed, with the implication that at times when desktop-file-utils
is not installed the database may hvae missing or extra entires?

Presumably this would involve rebuilding the database when
desktop-file-utils is installed or pkg_add'd, and rebuilding the
database when a package with a desktop entry is added/deleted at times
when desktop-file-utils is installed.


I'm not sure if this solves an existing problem - my wife's computer
has pretty recent gnome and gnumeric is somehow not registered to
handle .xls, and I can't seem to make it do that.  I suspect this is
an entirely separate issue, though.

-- 
        Greg Troxel <gdt@ir.bbn.com>