Gentoo Archives: gentoo-dev

From: Ian Stakenvicius <axs@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update
Date: Wed, 04 Sep 2013 19:48:35
Message-Id: 52278E88.2090609@gentoo.org
In Reply to: Re: [gentoo-dev] [PATCH] gnome2-utils.eclass add support for gdk-pixbuf cache update by Gilles Dartiguelongue
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA256
3
4 On 04/09/13 03:44 PM, Gilles Dartiguelongue wrote:
5 > Le mercredi 04 septembre 2013 à 15:23 -0400, Ian Stakenvicius a
6 > écrit : [snip]
7 >>
8 >> By gdk-pixbuf.cache , you mean the 'loaders.cache' file that the
9 >> eclass is now continuously updating? Which ebuild is going to
10 >> 'own' it?
11 >
12 > yes, gdk-pixbuf is going to own it since it is the main loader
13 > provider and the package that provides the tool to generate the
14 > cache.
15 >
16 >> Also, is it owned by anything right now? IIRC we don't try
17 >> particularly hard to support FEATURES="collision-protect" in the
18 >> tree, but rather FEATURES="protect-owned", and so if the file is
19 >> currently sitting there unowned by any package, afaik you
20 >> shouldn't get any collisions by installing over it.
21 >
22 > it is not owned by any package right now but touching the file in
23 > src_install made collision-protect abort the install.
24
25 You had FEATURES="collision-protect" enabled" or the default
26 FEATURES="protect-owned" ?
27
28 >
29 >> If you want to do that *and* maintain whatever is currently in
30 >> that file, you can use the trick sys-apps/openrc used to do: in
31 >> pkg_preinst, copy the system file (if it exists) into ${D}, and
32 >> then let that same copy be merged back into the system. Openrc
33 >> did it to get around CONFIG_PROTECT, but it had the unfortunate
34 >> side effect of making the package own the file. I don't know if
35 >> removal will be affected by this though if the contents of the
36 >> file change after the ebuild owning it was merged?
37 >
38 > That sounds like a good idea, I guess it does not cause a
39 > collision-protect error because the file is added to ${D} after
40 > comparison between ${D} and live file-system ?
41 >
42
43 No, it still does collide that first time if
44 FEATURES="collision-protect" is enabled. In fact, I do not believe
45 there is (by design) any way for this ebuild to 'take ownership' of a
46 file it doesn't already own without user intervention, if
47 FEATURES="collision-protect" is enabled.
48
49
50 -----BEGIN PGP SIGNATURE-----
51 Version: GnuPG v2.0.20 (GNU/Linux)
52
53 iF4EAREIAAYFAlInjogACgkQ2ugaI38ACPBzyQD9E6d71+zINTn6GWPPmOJHJL0I
54 K4IWNlanJJVE5WNpypkA/1bB1iYGQuVZIok1IssaGinme1FyJeUnDHy9PaXQTdTt
55 =sPlK
56 -----END PGP SIGNATURE-----

Replies