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 >> 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.
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. -- Thanks, Zac
