1 |
Le mercredi 04 septembre 2013 à 15:23 -0400, Ian Stakenvicius a écrit : |
2 |
> On 04/09/13 02:57 PM, Gilles Dartiguelongue wrote: |
3 |
[snip] |
4 |
> > Is there any other solution or is there any other point that would |
5 |
> > move the balance from one solution to another ? |
6 |
> > |
7 |
> > This solution would also be applied to a couple of other commonly |
8 |
> > regenerated files in Gnome ebuilds, like gtk-icon-cache, etc. |
9 |
> > |
10 |
> |
11 |
> By gdk-pixbuf.cache , you mean the 'loaders.cache' file that the |
12 |
> eclass is now continuously updating? Which ebuild is going to 'own' it? |
13 |
|
14 |
yes, gdk-pixbuf is going to own it since it is the main loader provider |
15 |
and the package that provides the tool to generate the cache. |
16 |
|
17 |
> Also, is it owned by anything right now? IIRC we don't try |
18 |
> particularly hard to support FEATURES="collision-protect" in the tree, |
19 |
> but rather FEATURES="protect-owned", and so if the file is currently |
20 |
> sitting there unowned by any package, afaik you shouldn't get any |
21 |
> collisions by installing over it. |
22 |
|
23 |
it is not owned by any package right now but touching the file in |
24 |
src_install made collision-protect abort the install. |
25 |
|
26 |
> If you want to do that *and* maintain whatever is currently in that |
27 |
> file, you can use the trick sys-apps/openrc used to do: in |
28 |
> pkg_preinst, copy the system file (if it exists) into ${D}, and then |
29 |
> let that same copy be merged back into the system. Openrc did it to |
30 |
> get around CONFIG_PROTECT, but it had the unfortunate side effect of |
31 |
> making the package own the file. I don't know if removal will be |
32 |
> affected by this though if the contents of the file change after the |
33 |
> ebuild owning it was merged? |
34 |
|
35 |
That sounds like a good idea, I guess it does not cause a |
36 |
collision-protect error because the file is added to ${D} after |
37 |
comparison between ${D} and live file-system ? |
38 |
|
39 |
-- |
40 |
Gilles Dartiguelongue <eva@g.o> |
41 |
Gentoo |