[pacman-dev] [PATCH] makepkg: improve srcdir check and add pkgdir

[Loui Chang]

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.