Therein lies a bit of the paradox of this kind of testing. Smaller packages really shouldn't need this kind of a check because a packager should be able to identify the dependencies necessary for a small package. Only the bigger packages that have dozens of dependencies would really be significantly aided by this. But for those packages, the feature would have to be disabled. Shouldn't namcap just do this and the packager can go back and fix his missed dependencies? Also I do agree that it decreases readability of PKGBUILD, the blackbox argument above. Just my thoughs. On Aug 15, 2009 10:13am, Christoph Schied <Christoph.Schied@uni-ulm.de> wrote:
On Sat, Aug 15, 2009 at 02:51:15PM +0000, matthewbruenig@gmail.com wrote:
When I worked on zenwalk's buildpkg which is basically a port of makepkg,
we had something like this to find dependencies. It is painfully slow on
applications of any significant size. Not a good idea.
I think it shouldn't that much of a problem, thats what we have split
packages for, and one could disable the feature for big packages
(thinking of texlive and that stuff).
greetings, Christoph Schied