On 06/12/2016 03:05 AM, Michał Górny wrote:
> Dnia 12 czerwca 2016 11:49:26 CEST, Zac Medico <zmed...@gentoo.org> 
> napisał(a):
>> On 06/12/2016 02:28 AM, Michał Górny wrote:
>>> Dnia 12 czerwca 2016 11:10:55 CEST, Zac Medico <zmed...@gentoo.org>
>> napisał(a):
>>>> On 05/22/2016 01:21 AM, Michał Górny wrote:
>>>>> Introduce a new logic for INSTALL_MASK handling in merging code,
>>>>> replacing the old code that removed matching files and directories
>>>>> from imagedir in bash. The new code actually ignores matching files
>>>>> on-the-fly while testing for file collisions and merging files.
>>>>> The files are still written to CONTENTS, and output using "###"
>> zing
>>>>> to indicate being masked, yet are not actually merged to the
>>>> filesystem.
>>>> Since collision-protect relies on existing files in its collision
>> test,
>>>> install-masked files are no longer going to trigger collisions.
>> Then,
>>>> since the install-masked files are still written to CONTENTS, it's
>>>> possible for the unmerge of one package to unmerge colliding files
>> that
>>>> belong to another package!
>>>> There are a number of ways to solve this problem. For example, we
>> could
>>>> have the unmerge code ignore any files in CONTENTS that match the
>>>> INSTALL_MASK value that was used at merge time.
>>> 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
>> Even then, we have to carefully consider how the absence of installed
>> files affects the collision test. It's safest for the unmerge code to
>> be
>> aware of the merge time INSTALL_MASK setting, and not try to unmerge
>> the
>> install-masked files.
> But then it wouldn't unmerge the newly masked files as well.

I'm suggesting to save the INSTALL_MASK setting from merge time, so any
new INSTALL_MASK settings since then are irrelevant.

> Getting this right will require a lot of effort, and we're less likely to 
> screw something up if we keep it simple.

You can use exactly the same pattern matching code for merge and
unmerge. It's worthwhile, given the say that collision-protect relies on
file existence in the collision test.

Reply via email to