Milestone Destinations

Completed 9 years ago (03/11/10 12:57:19)


Number of tickets:

7 / 7


1 / 1

Destinations support.


  • Ability to build binary packages
  • Support for proper dependency handling when ROOT is in use

Using Destinations

Controlling destinations:

  • paludis --install ... (install to the default destination)
  • paludis --destination mybinrepo --install ... (make a binary package)
  • paludis --destination mybinrepo --destination installed --install ... (make a binary package and also install it)
  • paludis --destination mybinrepo --allow-destination installed --install ... (make a binary package, and install any deps necessary)
  • paludis --destination mychroot --allow-destination installed --install ... (install to ROOT, and install any deps necessary)


These packages will be installed:

* dev-libs/some-dep-1.23 {:0} [N]
* dev-libs/some-other-dep-2.34 {:0} [N]
* app-misc/whatever-1.5 {:0} [N] foo -bar -> ::mybinrepo

Total: 3 packages (3 new)
  To ::installed: 2 packages (2 new)
  To ::mybinrepo: 1 package (1 new)

Implementation Details

A destination name is a repository name. The repository must support RepositoryDestinationInterface.

Must have some way of telling whether a repository can be used to satisfy certain dependency classes. A VDBRepository can satisfy deps only if ROOT=/. A binary repo can't satisfy deps.

Merge logic will be moved into the RepositoryDestinationInterface.

Not all destinations can receive all kinds of packages (e.g. CRANInstalledRepository cannot accept ebuilds).

Some destinations want runtime depends installed to them too (e.g. VDBRepository with ROOT!=/). Some don't by default (e.g. binary repos).

The PackageDatabase InstallOptions arg will no longer be sufficient. Instead:

  • Installed
  • Installed to satisfy a given dep class?
  • Installable
  • Installable to a particular location
Note: See TracRoadmap for help on using the roadmap.