3
26
Fork
You've already forked mere
1

fix: prevent false path conflicts from corrupted parent realization ownership #74

Merged
jhuntwork merged 1 commit from fix/bogus-path-conflict-from-corrupt-realization into main 2026年06月04日 00:55:50 +02:00

When a parent realization has paths attributed to the wrong package index
(e.g. due to packages being added/removed across generations shifting sorted
indices), the delta builder would seed those paths under the wrong owner.
If the real owner was later re-added, its projection would claim those paths
and trigger a spurious PathConflict error.

Fix: in addDeltaPackageProjectionToRealization, skip the conflict check when
the retained owner's store path matches the incoming package's store path.
The path was already seeded (correctly or via misattribution to the same
store), so there is no real conflict.

Also fix the skip guard in the finalizeAdmittedStoreObject test: the code
path under test only executes for privileged installs, so the test must skip
when NOT privileged rather than when root.

When a parent realization has paths attributed to the wrong package index (e.g. due to packages being added/removed across generations shifting sorted indices), the delta builder would seed those paths under the wrong owner. If the real owner was later re-added, its projection would claim those paths and trigger a spurious PathConflict error. Fix: in addDeltaPackageProjectionToRealization, skip the conflict check when the retained owner's store path matches the incoming package's store path. The path was already seeded (correctly or via misattribution to the same store), so there is no real conflict. Also fix the skip guard in the finalizeAdmittedStoreObject test: the code path under test only executes for privileged installs, so the test must skip when NOT privileged rather than when root.
fix: prevent false path conflicts from corrupted parent realization ownership
Some checks failed
/ test (pull_request) Failing after 6m19s
57638c28a1 
When a parent realization has paths attributed to the wrong package index
(e.g. due to packages being added/removed across generations shifting sorted
indices), the delta builder would seed those paths under the wrong owner.
If the real owner was later re-added, its projection would claim those paths
and trigger a spurious PathConflict error.
Fix: in addDeltaPackageProjectionToRealization, skip the conflict check when
the retained owner's store path matches the incoming package's store path.
The path was already seeded (correctly or via misattribution to the same
store), so there is no real conflict.
Also fix the skip guard in the finalizeAdmittedStoreObject test: the code
path under test only executes for privileged installs, so the test must skip
when NOT privileged rather than when root.
jhuntwork force-pushed fix/bogus-path-conflict-from-corrupt-realization from 57638c28a1
Some checks failed
/ test (pull_request) Failing after 6m19s
to e2a7a3287e
Some checks failed
/ test (pull_request) Failing after 5m46s
2026年06月04日 00:21:04 +02:00 Compare
jhuntwork force-pushed fix/bogus-path-conflict-from-corrupt-realization from e2a7a3287e
Some checks failed
/ test (pull_request) Failing after 5m46s
to e901043b05
All checks were successful
/ test (pull_request) Successful in 5m8s
2026年06月04日 00:49:56 +02:00 Compare
jhuntwork deleted branch fix/bogus-path-conflict-from-corrupt-realization 2026年06月04日 00:55:51 +02:00
Sign in to join this conversation.
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
merelinux/mere!74
Reference in a new issue
merelinux/mere
No description provided.
Delete branch "fix/bogus-path-conflict-from-corrupt-realization"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?