Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update

[Gilles Dartiguelongue]

Le mercredi 04 septembre 2013 à 15:23 -0400, Ian Stakenvicius a écrit :
> On 04/09/13 02:57 PM, Gilles Dartiguelongue wrote:
[snip]
> > Is there any other solution or is there any other point that would
> > move the balance from one solution to another ?
> >
> > This solution would also be applied to a couple of other commonly
> > regenerated files in Gnome ebuilds, like gtk-icon-cache, etc.
> >
>
> By gdk-pixbuf.cache , you mean the 'loaders.cache' file that the
> eclass is now continuously updating?  Which ebuild is going to 'own' it?

yes, gdk-pixbuf is going to own it since it is the main loader provider
and the package that provides the tool to generate the cache.

> Also, is it owned by anything right now?  IIRC we don't try
> particularly hard to support FEATURES="collision-protect" in the tree,
> but rather FEATURES="protect-owned", and so if the file is currently
> sitting there unowned by any package, afaik you shouldn't get any
> collisions by installing over it.

it is not owned by any package right now but touching the file in
src_install made collision-protect abort the install.

> If you want to do that *and* maintain whatever is currently in that
> file, you can use the trick sys-apps/openrc used to do:  in
> pkg_preinst, copy the system file (if it exists) into ${D}, and then
> let that same copy be merged back into the system.  Openrc did it to
> get around CONFIG_PROTECT, but it had the unfortunate side effect of
> making the package own the file.  I don't know if removal will be
> affected by this though if the contents of the file change after the
> ebuild owning it was merged?

That sounds like a good idea, I guess it does not cause a
collision-protect error because the file is added to ${D} after
comparison between ${D} and live file-system ? 

-- 
Gilles Dartiguelongue <eva@g.o>
Gentoo