On Sat, Nov 14, 2009 at 8:44 AM, Allan McRae <al...@archlinux.org> wrote: > Ciprian Dorin, Craciun wrote: >> >> Hy everybody! >> >> While building some custom packages for a stripped down Linux >> server, I've hit the following problems: >> * the cause of the problems is from the pact that my packages are >> each in it's own folder like: /packages/bash--4.0--1, >> /packages/busybox--1.15.2--1, etc., and thus, >> * MAN_DIRS, DOC_DIRS, STRIP_DIRS and PRUNE_TARGETS doesn't work, >> as I have no way to use ${pkgname}, etc in there; >> * in PRUNE_TARGETS there is no way to specify file patterns (like >> '*.a', or '*.la'), but only from certain folders; (for example I can >> say '*.a', but not '../lib/*.a'; also I can not specify unknown number >> of parents, like '.../lib/**/*.a'; >> >> As a consequence, I propose (and if accepted I also have the >> patches for) the following enhancements: >> * allow the patterns in MAN_DIRS, etc. to be evaluated at the >> proper time execution time (when we access MAN_DIRS), not at >> configuration time (when we define MAN_DIRS); this can be achieved by >> (single) quoting the patterns like: >> 'package/${pkgname}--${pkgver}--${pkgrel}/{,share/}man' and then >> expansion by using eval; > > You can use > > MAN_DIRS=({package/*/,}{usr{,/local}{,/share},opt/*}/{man,info}) > > and that will work. An eval statement is evil.
I don't know this for sure, but I assume that the makepkg.conf file is sourced before actually going to build or package. Thus in order for `package/*/` to work it must already exist in the current folder. For example I've searched makepkg.sh for where the config file is read, and I've found that it's hold in the MAKEPKG_CONF variable. And the only place it's sourced is just before executing anything. This means that (maybe) my previous assumption is right, and that `package/*` or `opt/*` doesn't work. I agree that `eval` is evil. (If you ask me Bash is the most evil programming language from them all, but I still do about 25% of my programming in Bash...) So coming back to eval, in order to make my use-case happen we have two options: * either we source MAKEPKG_CONF before each operation, * or we use eval on our patterns, and we single quote the patterns in the config file; >> * allow enhanced pattern types for PURGE_TARGETS, like: >> * the same lazy evaluation as above; >> * if a pattern starts with '=' then it must exactly match a file >> name; >> * if a pattern starts with '+' then it is a glob pattern (or >> globstar), like: >> 'packages/${pkgname}--${pkgver}--${pkgrel}/lib/**/*.a' > > These seem to be able to be handled in much the same way as MAN_DIRS above. No it is not. For example if I have usr/lib/something/libsomething.a, I cannot purge libsomething.a unless I explicitly say `*.a` (which could erase even other files in other folders), or `usr/lib/*/*.a`, which forces me to know that I have folders. (Thus eliminating the generality of makepkg.conf.) But again, it doesn't work, as explained above, because usr/lib/*/*.a should already exist at source time in order to work. >> * if a pattern ends with '/' then we use `rm -Rf`, else we use `rm >> -f` > > Instead of ending in /, end it in /* and combine with !emptydirs? Again it doesn't work. If a folder contain subfolders it shall eliminate only the files in the parent, but not files in children. Also emptyfolders is a packaging option, and purging should be able to remove a folder completely without leanig on the emptyfolders support. (For example there could be cases where a package should contain an empty folder.) >> * maybe if a pattern starts with '@' then it is a regular >> expression, etc. (this I have not implemented); >> >> Any comments? > > This all sounds overcomplicated. Before considering this further, I would > like to see an example that can not be handled by the current setup. > > Allan I hope that my examples are enough to show that there is a imitation in current *_DIRS and PURGE_TARGETS. If I'm wrong about the conf file sourcing please correct me, but from what I've seen I think I'm right. Thanks, Ciprian.