diff --git a/qpkg/TODO b/qpkg/TODO
index 2b34941..5111438 100644
--- a/qpkg/TODO
+++ b/qpkg/TODO
@@ -1,3 +1,107 @@
+Open policy decisions
+=====================
+
+- what to do about cyclic dependencies ?
+
+  A cyclic dependency can be bad new or something perfectly normal,
+  depending on how we define the semantics of package A depending on
+  package B, and what policy we adopt with respect to the existence of
+  cyclic dependencies:
+
+  1) "B must be installed before A"
+
+     In this case, a cyclic dependency means that the package in
+     question cannot be installed using the respective sequence of
+     installations.
+
+     However, this does not mean that no other sequence can exist in which
+     the package could be installed.
+
+     Example:
+
+     A depends on B. There are two versions of B: B_0 depends on nothing
+     else while B_1 depends on A.
+
+     If we try to resolve A's dependency with B_1, we enter a circular
+     dependency and fail. If we use B_0 instead, there is no problem.
+
+     This means that there are (at least) the following three possible
+     policies:
+
+     1A) Cyclic dependencies are tolerated and just mean that the package
+         in question may not be installable (for whatever reason).
+
+     1B) A cyclic dependency is always considered an error.
+
+     1C) Cyclic dependencies are tolerated as long as there is a way around
+         them, as in the example above.
+
+  2) "B must be installed with A"
+
+     In this case, the cyclic dependency would not be a problem as long as
+     all the packages in the cycle are installed together.
+
+     Should an installation get interrupted and cause only part of the
+     packages to get installed, the system would then be in an anomalous
+     configuration.
+
+     If cyclic dependencies are to be interpreted this way, they are not a
+     problem per se. Policy may still discourage their use, though.
+
+- what to do if we need something that's "provided" ?
+
+  When determining prerequisites, we may encounter a dependency on an item
+  that only appears in the Provides: field of a package but it not an
+  installable package itself.
+
+  Should we
+
+  1) consider installing the package that provides the requested item, or
+ 
+  2) ignore the package, leaving it to the user to choose what to do.
+
+  3) if there's only one choice do 1) else do 2).
+
+  ?
+
+  Policy 1 would make sense if this is merely an alias or if a package
+  enumerates its constituents, which at some point in time - in the past
+  or in the future - are separate packages.
+
+  Example:
+
+  - package "dwarf-pluto" could provide "planet-pluto", for packages that
+    haven't been updated yet,
+
+  - "binutils" could provide "as", "ld", etc., to allow packages that only
+    need specific parts to depend on them (with the option of breaking
+    binutils into its constituents in the future),
+
+  - similarly, if "as", "ld", etc., where individual packages in the past
+    but are now combined into "binutils", "binutils" could still provide
+    its constituents for compatibility with packages whose dependencies
+    have not been updated yet.
+  
+  Policy 2 would seem more appropriate in the common case of multiple
+  choices.
+
+
+  Example:
+
+  - packages "emacs" and "vim" could both provide "editor", leaving the
+    choice to the user.
+
+  - similarly, message packages "foo-en", "foo-zh", etc., could both
+    provide "foo-messages".
+
+  In the above example, "Provides" could also be use to prioritize choices,
+  e.g., if "foo-en" provides "lang-en" and "foo-zh" provides "lang-zh",
+  future installations could prefer prerequisites that introduce fewer new
+  items. So a package "bar-en" providing "bar-messages" and "lang-en" would
+  be chosen over "bar-zh" providing "bar-messages" and "lang-zh" if we have
+  already installed "foo-en" but not "foo-zh" (or vice versa).
+
+
 Still left to do
 ================