| 1 |
On 01/02/2013 10:13 PM, Alexandre Rostovtsev wrote: |
| 2 |
> On Thu, 2013-01-03 at 00:25 -0500, Rick "Zero_Chaos" Farina wrote: |
| 3 |
>> On 01/03/2013 12:06 AM, Michał Górny wrote: |
| 4 |
>>> On Wed, 02 Jan 2013 19:49:02 -0800 |
| 5 |
>>> ""Paweł Hajdan, Jr."" <phajdan.jr@g.o> wrote: |
| 6 |
>>> |
| 7 |
>>>> It came up again with <https://bugs.gentoo.org/show_bug.cgi?id=449918>, |
| 8 |
>>>> and I think it's worth to think about a better fix. I still keep hitting |
| 9 |
>>>> mysterious collisions with orphaned files from time to time. |
| 10 |
>>>> |
| 11 |
>>>> How about switching the developer profile from collision-protect to |
| 12 |
>>>> protect-owned, and proceeding with enabling protect-owned by default for |
| 13 |
>>>> all profiles? (not all developers are using the developer profile) |
| 14 |
>>> |
| 15 |
>>> Well, it all depends. |
| 16 |
>>> |
| 17 |
>>> protect-owned is easy and lazy. You just get errors on package |
| 18 |
>>> collisions, care about nothing else. |
| 19 |
>>> |
| 20 |
>>> collision-protect cares about every collision. It can help you notice |
| 21 |
>>> that *your* package lefts orphaned files for some reason or writes |
| 22 |
>>> where it is not supposed to write. |
| 23 |
>>> |
| 24 |
>> In the years I ran collision-protect I can say it prevented hundreds of |
| 25 |
>> merges of linux-firmware (because the kernel also installs firmware) and |
| 26 |
>> not much else. |
| 27 |
>> |
| 28 |
>> Would you be able to share more specific insight on how |
| 29 |
>> collision-protect helped protect files that need to be protected where |
| 30 |
>> protect-owned would have been inferior? |
| 31 |
> |
| 32 |
> It protects files that cannot be owned by any one package, but must still |
| 33 |
> be protected, for example /usr/share/glib-2.0/schemas/gschemas.compiled |
| 34 |
> |
| 35 |
> This file contains the compiled database of all your gsettings schemas. |
| 36 |
> It needs to be updated by running glib-compile-schemas every time you |
| 37 |
> install or remove a gsettings schemas xml file. Ebuilds for glib-based |
| 38 |
> stuff have to run glib-compile-schemas in pkg_postinst(), and the |
| 39 |
> gschemas.compiled must remain outside package manager control. |
| 40 |
> |
| 41 |
> However, some packages' build systems have "make" or "make install" call |
| 42 |
> glib-compile-schemas by default. A careless developer who doesn't use |
| 43 |
> collision-protect *and* doesn't pay attention to protect-owned's warning |
| 44 |
> messages might accidentally allow his ebuild to compile and install |
| 45 |
> /usr/share/glib-2.0/schemas/gschemas.compiled in src_install(), marking |
| 46 |
> the file as owned by his ebuild. When his ebuild is uninstalled, the |
| 47 |
> gschemas.compiled file would be removed, breaking the system. |
| 48 |
|
| 49 |
For special files like these, maybe it makes sense to delegate a single |
| 50 |
owner, have that owner do special handling in pkg_preinst. For |
| 51 |
gschemas.compiled, the natural owner would be dev-libs/glib:2 since it |
| 52 |
installs the glib-compile-schemas program. For special handling in |
| 53 |
pkg_preinst, it could do like preserve_old_lib in eutils.eclass, and |
| 54 |
copy the existing file from ${ROOT} to ${D}. |
| 55 |
-- |
| 56 |
Thanks, |
| 57 |
Zac |
Archives