Summary: | sys-apps/portage: removeFromContents FileNotFoundError with FEATURES=parallel-install | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Zac Medico <zmedico> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | Keywords: | InVCS |
Priority: | Normal | ||
Version: | 2.2 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 573774, 576786 |
Description
Zac Medico
![]() The list of blocked packages is evaluated inside the MergeProcess._spawn method. With parallel-install, the list of blocked packages can be stale by the time dblink.treewalk operates on the list with removeFromContents. This can be fixed by making dblink.treewalk detect stale items in the list of blocked packages, and skip removeFromContents calls for these items. (In reply to Zac Medico from comment #1) > This can be fixed by making dblink.treewalk detect stale items in the list > of blocked packages, and skip removeFromContents calls for these items. The blocked packages are also used in the _collision_protect call before the files are merged, so we should acquire a lock for _collision_protect, but only when there are blocked packages to account for. There's a patch in the following branch: https://github.com/zmedico/portage/tree/bug_576888 (In reply to Zac Medico from comment #3) > There's a patch in the following branch: > > https://github.com/zmedico/portage/tree/bug_576888 Withdrawing this patch for now, since I'm afraid that concurrent uninstall of one of the blocked packages could unmerge files that were just installed by the current package. We can make the Scheduler avoid these kinds of problems by placing conflicting packages in a queue to be processed serially. (In reply to Zac Medico from comment #5) > We can make the Scheduler avoid these kinds of problems by placing > conflicting packages in a queue to be processed serially. The scheduler won't be able to account for concurrent emerge/ebuild invocations, whereas locks can handle that very well. If we introduce locking at the package-slot level, then a package with blockers can trigger locking of all the blocked package-slots. This should minimize the amount of time that packages spend waiting on one another, and will allow for cooperation with concurrent emerge/ebuild invocations. (In reply to Zac Medico from comment #3) > There's a patch in the following branch: > > https://github.com/zmedico/portage/tree/bug_576888 There's a new patch in that branch, posted for review here: https://archives.gentoo.org/gentoo-portage-dev/message/8687ecc13cc170a7b75c1da34a15d91d This is in the master branch: https://gitweb.gentoo.org/proj/portage.git/commit/?id=dccd4687999aed1788dfe5c3461523f2b23ca79f Can i include the patch in sys-apps/portage-2.2.28 ? wget -O /etc/portage/patches/sys-apps/portage/bug_576888.patch https://gitweb.gentoo.org/proj/portage.git/patch/?id=dccd4687999aed1788dfe5c3461523f2b23ca79f and use it ? (In reply to marco from comment #9) > Can i include the patch in sys-apps/portage-2.2.28 ? > > wget -O /etc/portage/patches/sys-apps/portage/bug_576888.patch > https://gitweb.gentoo.org/proj/portage.git/patch/ > ?id=dccd4687999aed1788dfe5c3461523f2b23ca79f > > and use it ? Yes, that's fine. |