Background

This wiki page are raw notes in order to come up with a reasonable solution to the forest of issues surrounding packages dependencies, requirements, provides, meta packages and so on in the context of building system images.

Resolved:

  • The choice of which packages collectively make up a system should be possible.
  • A package ought to be able to replace another package without the need to modify either package. (And there ought to be a tool to validate the replacement)
  • The minimum base for a system should be able to be defined by those designing and building the system.
  • System ought to be able to define a "sparse" mode when it comes to information retained on the system to manage packages.

Definitions:

  • Dependency comes in the following forms:
    • Runtime : named package(s) must be present in order to successfully run
    • Install : named package(s) must be present in order for installation to be successful
    • Build : named package(s) must be present in order to build package
  • Add-on
    • Optional capability that can either on or off depending on how the package is built.
    • It should be reasonable that a package could be built several different ways depending on Add-ons that are enabled/disabled.
  • Collection
    • A set of packages defined by the creator of the system image.
      • Removing a packaged named in a collection should generate a strong warning.
    • A collection tool should be able to output all deps that would be pulled in as a result of it's use.
  • Provides

Workflow

Package

Image Building

  • build defined as named set of Collections and Packages
    • Build can use predefined collections, override collections or it's own.
  • build can define which Add-ons are off, Add-ons not named are presumed to be on.

System

TomGall/DepsRequiredProvidesMess (last modified 2011-08-26 17:03:25)