On Thu 30 Sep 2010 12:38 +1000, Allan McRae wrote:
On 30/09/10 12:26, Loui Chang wrote:
On Thu 30 Sep 2010 12:10 +1000, Allan McRae wrote:
On 30/09/10 11:56, Loui Chang wrote:
On Wed 29 Sep 2010 21:59 +1000, Allan McRae wrote:
The checking of the package for $srcdir references was overly sensitive and gave a lot of what appear to be false positives with binary files (in particular with debugging symbols kept).
Restrict the search for $srcdir to non-binary files as this should still catch the majority of configuration issues the check was initially designed to catch. Also, add a similar check for $pkgdir.
Just curious. Shouldn't these checks really be part of namcap rather than makepkg?
How would namcap know where a package was built?
I haven't thought of the implementation. How would you implement it?
I wondered since namcap is the package checking tool that it should have such functionality rather than makepkg itself.
Perhaps makepkg could hand things off to namcap if the packager wishes to check the package for any issues.
There are reasons not to have makepkg pass stuff directly to namcap. Primarily, I do not have (or want) python in my clean chroots so namcap would not run there. The only other way would be to put a reference to the build root somewhere in the .PKGINFO file so that namcap could read it in and check for it but I do not like the idea of putting that sort of stuff there.
I wasn't implying that package checking should be forced. Well, package checking via namcap should remain optional. Maybe checking for $srcdir references could also be optional. I don't know if putting a reference to the build root would be a good idea. I think it could be something passed directly to namcap immediately after building.
Overall, I agree that makepkg should not do much package checking, but this is something best suited to being in makepkg. I would definitely not like the checks performed by makepkg to unnecessarily expand beyond anything that can be done in 1 or 2 lines of bash...
Yep. I'm just brainstorming different possibilities. I'm glad to have feedback about it. Cheers.