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 <e...@gentoo.org>
Gentoo
signature.asc
Description: This is a digitally signed message part
