On Thu, 2005-01-27 at 10:01 -0500, Greg Troxel wrote:
>   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.

It'd be more or less the same, but if we go the .mk route, I don't plan
to automatically add entries in the PLIST in ANY WAY.  It's nonsense;
they will always be installed in the same place and with the same name.
(On a not-so-unrelated note, rc.d installation should be changed to not
generate plist entries automatically, but that's another issue.)

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

Yes.  This is another reason why I don't like an extra .mk file nor a
variable (and is my main concern).  It will easily confuse users: "huh,
this package installs a desktop file and has the variable defined, but
this other also installs a file but doesn't have the variable.  oh!
let's file a pr!".

OTOH, if it is made intelligently enough to avoid the need of listing
basenames in the package Makefiles, that'd be different and I'd like
it.  We'd then force all packages installing .desktop files to define a
variable (say, USE_DESKTOP=YES; better suggestions accepted) regardless
where the files come from (i.e., either from pkgsrc or from the
distfile).

Hmm... after rereading the above paragraph, I think it sounds good.
That could avoid the issue of forgetting to include desktopdb.mk if
the desktop files have MimeType entries, as we'd simply include it
unconditionally).

>   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?

No.  If it is not installed, the database does not exist at all.
When the package is installed, the db is created, and when the package
is deinstalled, the db is removed.

> 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.

That's the plan.  All files with .desktop entries will have some hooks
in their install scripts to verify that update-desktop-database is
installed and, in such case, run it during (de)install.

> I'm not sure if this solves an existing problem - my wife's computer

I'm not trying to fix an existing problem.  There is already a framework
in pkgsrc (i.e., desktopdb.mk) to update the mime database when needed.
And nobody has complained yet because it's only used so far by GNOME
related packages (the dependency chain is already big enough).

But if we start adding desktop files here and there, it becomes
insufficient ("what? a console application needing a tool to update
menus?"), so this is why it needs to be slightly improved.

> 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.

I don't have gnumeric installed ATM, but I see that its Makefile does
not include desktopdb.mk.  You can check if its gnumeric.desktop file
has a MimeType entry and, if so, include desktopdb.mk in the Makefile,
rebuild and reinstall gnumeric.  If it works, please file a PR :)

Cheers,

-- 
Julio M. Merino Vidal <jmmv84@gmail.com>
http://www.livejournal.com/users/jmmv/
The NetBSD Project - http://www.NetBSD.org/