Managing dependency lifecycle

[dgkf]

from discussion at R Validation Hub repos wg weekly standup

When considering how this will interact with a destination repository, we were considering different ways of handling dependencies.

Assuming there's a repository of validated packages, we might consider a new package request in the context of the packages already available. Dependencies of a new package might have version requirements that could be:

• Already satisfied
• Satisfied, but with updated versions available
• Unsatisfied, requiring a version upgrade
• Unsatisfied, requiring a version downgrade (this is probably very unlikely, and probably not worth extensively planning around this condition)
• Unavailable

The actions that are taken in each condition will inform how we want to handle dependency validation. Some possible paths might include:

• Never handle dependencies, only validate packages if all dependencies are already satisfied by packages already in the repository
• When new dependencies or dependency upgrades are required, also validate those packages and upgrade them in the repository

And finally, there's a decision to be made about how this will affect the documentation associated with each package. Should a package's report include information about the validation of its dependencies, or is it sufficient to have this information in a separate report - one for each package on the repository.