desktop-file-install for all desktop files?

[Fernando Lopez-Lezcano]

On Sat, 2006-12-23 at 00:07 +0200, Ville Skyttä wrote:
> On Fri, 2006-12-22 at 13:46 -0800, Fernando Lopez-Lezcano wrote:
> 
> > One (perhaps) very minor point about desktop files. Before packaging for
> > fe I used to create the .desktop file with a cat << EOF statement in the
> > spec file. Now I'm using a separate desktop file as suggested. The thing
> > I can't (easily) do that I was doing before was to include the full path
> > of the executable by using a %{_bindir}/name statement in the inline
> > desktop file.
> 
> If that's what one wants, it's only a sed oneliner away, so it's not
> exactly that hard either.

Yeah, I agree. I don't know what's the original rationale for not doing
an inline and forcing packages to have an extra file...

> >  That ensures that the menu starts what you actually think
> > you are starting and not whatever is first in your PATH that matches
> > that name.
> 
> Mileages vary whether that's a feature or a bug.  I think feature: if
> there's something in one's $PATH that is completely different from the
> executable the .desktop file is intended for, that's a clash that is not
> at all limited to menu entries and should be fixed anyway somewhere
> else.  On the other hand, if one has the same thing installed somewhere
> else so it is in $PATH before the /usr/bin one, chances are pretty good
> that it's there for a reason [1], and I don't think it's unreasonable
> for the menu entry to launch that too, just like what happens on the
> console when it's not invoked with an explicit path.
> 
> [1] eg. different version, locally tweaked build, wrapper script that
>     sets some desired command line options or environment variables, ...

I agree it can be seen as a feature. From my POV as a packager it is not
as I would prefer whatever is in the menu start what was actually
installed - unless I also customize the desktop file as well, in which
case the different behavior is intended explicitly. 

-- Fernando