[paludis-dev] [Paludis] #1367: Handling of dependencies across slash, chroot and binaries

Paludis 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:

 !   sys-libs/e2fsprogs-libs
     Reasons: sys-fs/e2fsprogs-1.43.6:0::installed-slash, sys-
     Unsuitable candidates:
     * sys-libs/e2fsprogs-libs-1.44.2:0::gentoo
     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
 code like:

     const std::shared_ptr<const PackageIDSequence>
                 generator::All() |

     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
 acceptable approach?

Ticket URL: <http://paludis.exherbo.org/trac/ticket/1367>
Paludis <http://paludis.exherbo.org/>
Paludis, the Other Package Mangler

More information about the paludis-dev mailing list