Subject: Re: Desktop files
To: Julio M. Merino Vidal <email@example.com>
From: Greg Troxel <firstname.lastname@example.org>
Date: 01/27/2005 10:01:12
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 <email@example.com>