After having a look at the integrity check source, it looks like it should deal with provivions already, but that code is obviously broken. If you could come up with a fix that would be very nice.
:-/ It does look like it handles it fine. I _was_ going to ask if I could test things out in my local machine without mirroring a whole repo when it occurred to me that maybe the script is not the bug. The issue is that the provides array in the perl PKGBUILD is dynamically generated via a perl script. If I were a lesser person[1], I might comment on the fact that a package is a make-dependency of itself. So new question: Is it okay if the dbscript ran an external perl script, grabbed the output, and parsed that? For just the provides field? For any field? How many packages use this sort of script (answer - something on the order of tens)? Make an exception for perl? Ask to have the provides array static in the PKGBUILD, even if it's dynamically generated at the source? Or figure out how provisions are actually established in the perl provides.pl and force (slash ask Mr. Justin Davis to) the script to create a bash-style environment variable instead of what it currently does (which seems like just printing the list of provisions)>Abandon it and continue having perl non-errors in the integrity check? Thoughts? MAQ. [1] Also, if I hadn't tried to see what would happen if I `pacman -Rc perl`. Who knew that pacman followed from that set (pacman -> curl -> opennssl -> perl -- I sense a game in the making: What is the longest chain of dependencies to perl)?