|author||Nicolás Reynolds <firstname.lastname@example.org>||2012-11-05 15:38:49 -0300|
|committer||Nicolás Reynolds <email@example.com>||2012-11-05 15:38:49 -0300|
Updated treepkg docs
Diffstat (limited to 'doc')
1 files changed, 14 insertions, 10 deletions
diff --git a/doc/treepkg.markdown b/doc/treepkg.markdown
index 2808599..7f7ece1 100644
@@ -13,9 +13,9 @@ some design issues that made fullpkg miss some packages sometimes.
`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.
@@ -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
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.