2 files changed, 74 insertions, 10 deletions
diff --git a/doc/treepkg.markdown b/doc/treepkg.markdown
index 2808599..7f7ece1 100644
--- a/doc/treepkg.markdown
+++ b/doc/treepkg.markdown
@@ -13,9 +13,9 @@ some design issues that made fullpkg miss some packages sometimes.
 ## Requirements
 
 `treepkg` needs the help of `toru-path` for "indexing" an ABS tree. `toru-path`
-stores a plain text database of "pkgname:path" pairs, where pkgname is replaced
-by the "pkgbase", "pkgname", and "provides" fields of a PKGBUILD, followed by
-the path of the current PKGBUILD.
+stores a tokyocabinet database of "pkgname" => "path" pairs, where pkgname is
+replaced by the "pkgbase", "pkgname", and "provides" fields of a PKGBUILD,
+followed by the path of the current PKGBUILD.
 
 This information is then used by `treepkg` to know where to find the PKGBUILD
 of a package. The fullpkg family needed to guess this by traversing the full
@@ -24,9 +24,9 @@ pkgbase.
 
 So, to use `treepkg` you need to run `toru-path` after the ABS tree update.
 
-> Currently `toru-path` doesn't remove duplicated or updated pairs, but it
-> picks the last ones and only processes new PKGBUILDs. This means `toru-path`
-> works correctly but it's database will grow up slowly.
+> Split PKGBUILDs make it difficult to extract metadata if it's stored inside
+> package() functions. This will happen with the provides field and `treepkg`
+> won't find that linux-libre-headers provides linux-headers, for instance.
 
 ## How does it work
 
@@ -105,6 +105,9 @@ current one. Thus this will become the build path:
     ghostscript (0) - fontconfig (buried)
                     \ cups (1)            - fontconfig (2)
 
+> Note: currently, `treepkg` doesn't perform recursive burying, so if you hit
+> a really long build tree with some circular dependencies you may find
+> packages buried several times and queued to build before their actuals deps.
 
 ## Tips 
 
@@ -114,13 +117,14 @@ to pass this arguments when running it manually, they're used internally to
 automatically construct the build path.
 
 But if a build failed, `treepkg` will cancel itself immediately informing you
-where the leftovers files where left. If you pass this path to `treepkg` as the
+where the leftovers files were left. If you pass this path to `treepkg` as the
 first argument, it will resume the build, skipping to the last package being
 packaged.
 
 You can take the opportunity given by this to modify the build path or the
-PKGBUILDs, without having to re-run `treepkg` twice. For instance you can
-remove a package from the build order, or move it manually, or update the
-PKGBUILD that made `treepkg` fail in the first place.
+PKGBUILDs, without having to run `treepkg` twice. For instance you can remove
+a package from the build order, or move it manually, or update the PKGBUILD
+that made `treepkg` fail in the first place. You can force a skipped package
+(after building it manually) by using `touch built_ok` on the PKGBUILD dir.
 
 You don't probably want to mess with the second argument though.
diff --git a/doc/workflows.markdown b/doc/workflows.markdown
new file mode 100644
index 0000000..f55ae7e
--- /dev/null
+++ b/doc/workflows.markdown
@@ -0,0 +1,60 @@
+# Workflows
+
+Describe your packaging workflow here!
+
+
+## fauno's way
+
+During packaging, I don't usually restart a build from scratch if I have to
+make changes to the PKGBUILD. I use a lot of commenting out commands already
+ran, `makepkg -R`, etc. When I used `libremakepkg` I ended up using a lot more
+`librechroot` and working from inside the unconfigured chroot, because
+`makechrootpkg` (the underlying technology for `libremakepkg`) tries to be too
+smart.
+
+When I started writing `treepkg` I found that mounting what I need directly on
+the chroot and working from inside it was much more comfortable and simple than
+having a makepkg wrapper doing funny stuff (for instance, mangling makepkg.conf
+and breaking everything.)
+
+This is how the chroot is configured:
+
+* Create the same user (with same uid) on the chroot that the one I use regularly.
+
+* Give it password-less sudo on the chroot.
+
+* Bind mount /home to /chroot/home, where I have the abslibre-mips64el clone.
+
+* Bind mount /var/cache/pacman/pkg to /chroot/var/cache/pacman/pkg
+
+* Put these on system's fstab so I don't have to do it everytime
+ 
+* Configure makepkg.conf to PKGDEST=CacheDir and SRCDEST to something on my home.
+
+Workflow:
+
+* Enter the chroot with `systemd-nspawn -D/chroot` and `su - fauno`.
+
+* From another shell (I use tmux) edit the abslibre or search for updates with
+  `git log --no-merges --numstat`.
+
+* Pick a package and run `treepkg` from its dir on the chroot, or retake
+  a build with `treepkg /tmp/package-treepkg-xxxx`. (Refer to doc/treepkg
+  here).
+
+What this allows:
+
+* Not having to worry about the state of the chroot. `chcleanup` removes and
+  adds packages in a smart way so shared dependencies stay and others move
+  along (think of installing and removing qt for a complete kde rebuild).
+
+* Building many packages in a row without recreating a chroot for every one of
+  them.
+ 
+* Knowing that any change you made to the chroot stays as you want (no one
+  touches your makepkg.conf)
+
+* Hability to run regular commands, not through a chroot wrapper. I can `cd` to
+  a dir and use `makepkg -whatever` on it and nothing breaks.
+
+* No extra code spent on wrappers.