Forwarding to pacman-dev. The idea seems reasonable to me as this check was mainly to catch bad paths in configuration files. Allan -------- Original Message -------- Subject: [arch-general] Makepkg $(srcdir) detection and false-positives Date: Fri, 27 Aug 2010 08:58:28 +0100 From: Nathan Wayde Reply-To: General Discussion about Arch Linux Organization: Konnichi Computing To: General Discusson about Arch Linux I'm not sure if this is the correct ML or not but whatever I'll post here anyway. I was just reading the ML where the quest? to finding why makepkg warns about $srcdir was brought up and a simple grep -R... seemed to be the method of detection. Anyway it reminded me of another message on the topic last week i think where someone said that it would warn on files with debugging symbols... TL;DR makepkg does a grep -q to decide if a package contains files that reference $(srcdir), this is inadequate as it causes a false-positive on files that contain debugging symbols. This can be eliminated by specifying the option `-I` a.k.a `--binary-files=without-match` to grep which makes prevents grep from matching binary files. Rationale: the only paths that binary files should contain based on buildtime setting are path such as '/usr/share/xyz'. If the pkgbuild *accidentally* uses a variable that resolves with $srcdir in it then I'd argue that the pkgbuild is broken and will most likely break the application in other ways and will be caught before sharing the pkgbuild. I can't be the only one that tests their packages before uploading to the AUR right? On another note, shouldn't there also be a check for $pkgdir. The only cases of this that I've ran into myself have been a reference to $pkgdir causing all sorts of nonsense such as broken symlinks and incorrect resource paths.