Language packs and desktop entries

[Joerg Barfurth]

Hi,

Mark McLoughlin wrote:
> Hey,
> 	To summarise the discussion we had at GUADEC around this issue, we
> talked about two solutions.
> 

I missed most of  these discussions, but still have comment:


>   2) The install-time merging of translations into the .desktop file.
> 
>      What I like about this is that the solution basically just 
>      involves some straightforward build/install infrastructure work 
>      and no other changes.
> 
>      The main problem I see here is that we'd be making it impossible 
>      (or at least much more difficult) for the package management system
>      to keep track of the .desktop file contents. Essentially, if you 
>      were doing language packs with RPM you'd have to do the following
>      in the base package:
> 
> %verify(not md5 mtime size) %{_datadir}/applications/*.desktop
> 
>      which certainly isn't ideal.
> 

Yes. Files that are not owned by a single package but accumulate 
contents from multiple packages are a pain. They also require special 
care to support proper uninstall. Another problem are package 
collisions. In most cases these go undetected, producing somewhat random 
results at install and completely breaking on uninstall.

Beyond this, post-install actions that are not simple scripts may also 
be a problem. Some packaging systems allow installing to a system 
instance that is different from the one the installer runs in. Running 
binaries that may exist only on the target system causes problems here. 
(Note: I don't know anything about the merging tool you'd want to use.)

Ciao, Joerg

-- 
Joerg Barfurth              Sun Microsystems - Desktop - Hamburg
 >>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<<
Software Engineer                         joerg.barfurth at sun.com
OpenOffice.org Configuration          http://util.openoffice.org