[paludis-dev] [Paludis] #1367: Handling of dependencies across slash, chroot and binaries
trac-paludis at exherbo.org
Tue Jun 5 15:08:16 UTC 2018
#1367: Handling of dependencies across slash, chroot and binaries
Reporter: zimous | Type: defect
Status: new | Priority: Sometime
Milestone: | Component: core/paludis/resolver
Version: scm | Keywords:
Blocked By: | Blocking:
Distribution: N/A |
When installing in chroot (only, with -/n) or creating just binaries,
paludis considers dependents and blockers also for slash. This is
misguided and blocks the resolution, e.g. if trying to install a newer
version into chroot than which is present in slash.
I am trying to setup chroots, where I would prepare and test large updates
for several machines. I am using gentoo, but afaik it is irrelevant.
I have two environments, : for the slash and :ch for the chroot.
I share the installable repositories between slash and chroot.
In slash I have just 1 VDB repository ::installed.
In chroot I have 2 VDB repositories, ::installed-chroot with root=/chroot
and ::installed-slash with root=/, which points to the ::installed of
In slash I have outdates packages and I am trying to bootsrap fresh up-to-
date installation in chroot.
Now trying, e.g., "cave -E :chroot resolve -Mr -/n e2fsprogs" yields:
Reasons: sys-fs/e2fsprogs-1.43.6:0::installed-slash, sys-
Did not meet ~sys-libs/e2fsprogs-libs-1.43.6, use existing if
possible, installing to / from sys-fs/e2fsprogs-1.43.6:0::installed-slash
Note that the blocker comes from ::installed-slash while installing into
::installed-chroot. Similarly weird things happen when uninstalling from
::installed-chroot or just creating a binary (sic!).
*) I really need the ::installed-slash repository present since otherwise
calls to "has_version --host-root" from, e.g., autotools.eclass fail.
The cause is that handling of dependencies is not really target (root)
aware. For example, in _collect_staying() and _resolve_dependents() is
const std::shared_ptr<const PackageIDSequence>
Resolvent resolvent(package, dt_install_to_slash);
Note the hardcoded "system_root_key()" and "dt_install_to_slash"
completely ignoring the target of original resolvent. Similarly in
several other places, so it would be a considerably larger change to fix
I may attempt to prepare a patch, but it will take several weeks before I
start, I have plenty of other work to do. My idea is to parametrize the
resolver steps like _resolve_dependents() by the path of root a call them
completely separately for slash and possibly for chroot. Would that be an
Ticket URL: <http://paludis.exherbo.org/trac/ticket/1367>
Paludis, the Other Package Mangler
More information about the paludis-dev