docs: describe dependencies and changes to package repo (#316)

website/docs/03_components/02_package-operator.md

@@ -7,6 +7,7 @@ The package operator follows the [Kubernetes Operator Pattern](https://kubernete
 The Package controller manages the `Package` resources of the cluster. 
 
 Whenever a `Package` has been created, changed or deleted these changes will be picked up and applied by the Package controller.
+The Package controller also makes sure that dependencies of a `Package` are met without conflicting installations, by applying the logic described [here](#dependency-management).
 
 ## PackageInfo Controller
 
@@ -70,13 +71,16 @@ Instead of fetching `repository.xyz/package-name/package.yaml`, the operator fet
 
 Check the [package repository documentation](../package-repository#structure) for more information.
 
-## Dependency Management (WIP)
+## Dependency Management
+
+Dependency Management is a cross-cutting concern that is being handled in all glasskube components (GUI, CLI, Operator). 
+The following decision tree states how the Package Operator is handling dependencies. 
 
 ### Package Operator – reconciling package P depending on package D (P -> D):
 
 #### Assumptions:
-* Each involved referred package has status Ready, i.e. none of the referred packages are currently being deleted or updated, and their installation has not failed
-* Each involved referred package has a `Spec.PackageInfo.Version` set, and it is equal to its `Status.Version`
+* Each involved referred package has status Ready, i.e. none of the referred packages are currently being deleted or updated, and their installation has not failed.
+* Each involved referred package has a `Spec.PackageInfo.Version` set, and it is equal to its `Status.Version`.
 * When the result of a situation is a dependency conflict, it might either be resolvable or not. Either way, the operator does not resolve such a conflict directly, but rather
 the components interacting with the user (CLI, UI) need to guide them through potential resolution. Consequently, the only time the operator does resolve an unfulfilled
 dependency, the "result" is denoted as `install`. 

website/docs/03_components/03_package-repository.md

@@ -13,8 +13,6 @@ A package repository must use the following directory structure to be fully comp
 ```
 |-- index.yaml
 |-- package-a/
-| |-- package.yaml
-|-- package-b/
   |-- versions.yaml
   |-- v1.2.3/
   | |-- package.yaml
@@ -24,7 +22,13 @@ A package repository must use the following directory structure to be fully comp
 
 The root `index.yaml` contains a list of all packages available from this repository. It is used primarily by client software to aid explorability.
 All files related to a package reside in a directory that must have the same name as the package. 
-Inside a package's directory there may be a `versions.yaml` that contains a list of all versions available for this package.
-If such a `versions.yaml` file exists, there must be a subdirectory for each version containing a `package.yaml` file.
-If no `versions.yaml` file exists, there must be a `package.yaml` in the package's directory.
+Inside a package's directory there must be a `versions.yaml` that contains a list of all versions available for this package.
+There must be a subdirectory for each version containing a `package.yaml` file.
 A `package.yaml` contains a manifest of that package which holds information such as longer descriptions and included files.
+
+## Package Manifest
+
+### Dependencies
+
+A package can declare dependencies that need to exist in a cluster, before the desired package can be installed. 
+Each dependency is a Glasskube package identified by its name. Optionally, a specific version or version range can be defined.