Subject: Re: Creating better packager's documentation
To: Thomas Klausner <>
From: Roland Illig <>
List: tech-pkg
Date: 08/11/2004 18:16:46
Thomas Klausner wrote:
> Hi!
> Packages.txt is getting quite unwieldy, and I don't think that it
> is a good basis for new-comers to learn how to create packages.
> Are some people interested to work on a packager's guide (that
> could live in e.g. wip/*.txt)?

I'm interested. I already started with some ideas myself. First I tried 
to guess what variables may be used (read/written/appended/defined) by 
both the package and the build system. I also thought about how 
variables can be partitioned into groups that can be remembered more easily.

Some groups are:
- commands (SED, AWK, CP, MV, ...)
- package options (USE_*)

> For the ones that don't want to work on this themselves:
> How did you start making packages? What could you use, what did
> you have to find out by asking people or looking at other packages?

I once wrote a Perl script that listed all the variable names that do 
not start with an underscore. Currently there are 830 variables. It's 
clear that it takes much time to learn all these.

grep -hr '^[A-Z]' *.mk */*.mk |sed -e 's,[^A-Z_0-9].*,,'|sort|uniq|less

During the last months I often grepped through ./mk/ and read a lot, so 
I nearly got the idea how the variables are called. But there are some 

I would like to rename ALL_TARGET to BUILD_TARGET in analogy to 
INSTALL_TARGET. ALL_TARGET may make sense if you know the history of 
pkgsrc (just guessing) but I find BUILD_TARGET more intuitive.

I think most of the package specific variables should be moved outside 
./mk/ to reduce the complexity of the base system, especially if they 
are only used in one package.

Another group of variables are the ones that are only used internally. I 
think of *_MK to prevent multiple inclusion and PHASES_AFTER_*. Other 
candidates might be *_COOKIE. All these variables should start with an