1 |
On 06/12/2016 02:28 AM, Michał Górny wrote: |
2 |
> Dnia 12 czerwca 2016 11:10:55 CEST, Zac Medico <zmedico@g.o> napisał(a): |
3 |
>> On 05/22/2016 01:21 AM, Michał Górny wrote: |
4 |
>>> Introduce a new logic for INSTALL_MASK handling in merging code, |
5 |
>>> replacing the old code that removed matching files and directories |
6 |
>>> from imagedir in bash. The new code actually ignores matching files |
7 |
>>> on-the-fly while testing for file collisions and merging files. |
8 |
>>> The files are still written to CONTENTS, and output using "###" zing |
9 |
>>> to indicate being masked, yet are not actually merged to the |
10 |
>> filesystem. |
11 |
>> |
12 |
>> Since collision-protect relies on existing files in its collision test, |
13 |
>> install-masked files are no longer going to trigger collisions. Then, |
14 |
>> since the install-masked files are still written to CONTENTS, it's |
15 |
>> possible for the unmerge of one package to unmerge colliding files that |
16 |
>> belong to another package! |
17 |
>> |
18 |
>> There are a number of ways to solve this problem. For example, we could |
19 |
>> have the unmerge code ignore any files in CONTENTS that match the |
20 |
>> INSTALL_MASK value that was used at merge time. |
21 |
> |
22 |
> Hmm, thinking about this more widely (i.e. actually thinking rather than mimicking the old behavior), I think it would be better to actually use the original file set for collision-protect. This will make it possible to detect collisions that would otherwise be hidden via INSTALL_MASK. |
23 |
|
24 |
Even then, we have to carefully consider how the absence of installed |
25 |
files affects the collision test. It's safest for the unmerge code to be |
26 |
aware of the merge time INSTALL_MASK setting, and not try to unmerge the |
27 |
install-masked files. |
28 |
-- |
29 |
Thanks, |
30 |
Zac |