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
>via INSTALL_MASK.
>
>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. Getting this right 
will require a lot of effort, and we're less likely to screw something up if we 
keep it simple.


-- 
Best regards,
Michał Górny (by phone)

Reply via email to