Subject: Re: KDE, gtk2+ and hicolor-icon-theme
To: Mark Davies <mark@mcs.vuw.ac.nz>
From: Julio M. Merino Vidal <jmmv84@gmail.com>
List: tech-pkg
Date: 01/19/2007 10:00:13
On 19/01/2007, at 0:02, Mark Davies wrote:

> On Thursday 18 January 2007 22:08, Julio M. Merino Vidal wrote:
>
>
>> hicolor-icon-theme could be modified to only run the
>> gtk-update-icon-cache utility if, and only if, it is already
>> installed. Be aware that doing so will also require changes to gtk2
>> so that the utility is run if gtk2 is installed _after_
>> hicolor-icon-theme.
>
>> (This scheme could be applicable to many other install scripts that
>> we have
>> in pkgsrc now...  I guess this could be generalized to that
>> "triggers" proposal, made by joerg@ IIRC.)
>
> I don't remember the "triggers" proposal but below is a first cut at
> the specific case.
>
> I don't particularly like the ${PREFIX} in referencing the path from
> the other package - is there a way to do the equivalent of
> ${BUILDLINK_PREFIX.package} without pulling in a dependency on the
> package?  Also not sure how this interacts with pkgviews or the
> destdir stuff.

There is that EVAL_PREFIX thing, to be used in this case.  You'll  
have to
use it to construct the appropriate path to the tool and then stick the
result into the install scripts.  Grep for it in the current packages; I
don't remember the exact syntax now.

WRT the patches, the cache now depends on gtk2, so it should be removed
upon gtk2's deinstallation (something that your patch doesn't seem to  
do).
Or when hicolor-icon-theme is removed... whichever happens first (but  
this
is already done).

Also the fact that gtk2 has to "know" about hicolor-icon-theme feels
weird... but we can't probably do better without something a lot more
complex.  So I'd say go for it.

-- 
Julio M. Merino Vidal <jmmv84@gmail.com>