Pinned down the collected problems of the current pkglint development.

1 files changed, 33 insertions, 0 deletions

diff --git a/pkgtools/pkglint/README b/pkgtools/pkglint/README
new file mode 100644
index 00000000000..17a920abf5b
--- /dev/null
+++ b/pkgtools/pkglint/README
@@ -0,0 +1,33 @@
+$NetBSD: README,v 1.1 2006/02/04 04:10:12 rillig Exp $
+
+== Current problems ==
+
+The current pkglint architecture will not scale much further. What is
+needed next are parsers for nested, non-context-free languages (make(1),
+sh(1), sed(1)). The parsers should be able to recognize partial
+structures, as well as structures containing foreign parts. This is
+because most of pkgsrc is heavily based on preprocessors:
+
+- The .if and .for directives in Makefiles are preprocessed by make(1)
+  before building dependencies and shell commands out of the remaining
+  text.
+
+- make(1) assembles shell commands from literal text and variables like
+  ${PKGNAME}.
+
+- Shell commands often use dynamic evaluation of variables.
+
+All this makes enhancing pkglint non-trivial. If you know of any
+academic papers that might be of help in this case, please tell me.
+
+Additionally, the Perl programming language is not well suited to this
+kind of tool. It does not provide:
+
+- Sufficient static checking (especially for names of methods)
+- A type system (you can apply almost any operator to any kind of data)
+- Object orientation (needed for the future advanced parsers)
+- Narrow scope for constants (it's just ugly)
+- Enumeration data types
+- Structured data types
+
+The pkglint source code is much too big for a single file.