[buildd-tools-devel] Bug#844267: Bug#844267: Bug#844267: Bug#844267: sbuild: Support for blhc

[Johannes Schauer]

Hi,

Quoting Mattia Rizzolo (2016-11-14 14:32:06)
> On Mon, Nov 14, 2016 at 06:23:45AM -0700, Sean Whitton wrote:
> > Hello,
> > 
> > On Mon, Nov 14, 2016 at 06:40:25AM +0100, Johannes Schauer wrote:
> > > sbuild supports running lintian, autopkgtest and piuparts because they are (or
> > > should) be applicable to *all* Debian packages.
> > > 
> > > blhc on the other hand is only applicable for packages that run gcc at some
> > > point during the build and will never be useful for all the other packages. So
> > > instead of adding a checker for gcc-based packages today, one for OCaml
> > > packages tomorrow and then 20 more for all the other programming languages we
> > > have in Debian, I'd rather implement support for a wrapper to these tools which
> > > is then doing the right thing.
> > 
> > Good point.  I didn't think of that.
> 
> This is actually not a problem: blhc is perfectly able to run on any
> build log, no metter whether actual compilers were run or if there
> wasn't any actual compiling involved.
> It has a specific return code (1) for those cases.  See the bottom of
> blhc(1), "EXIT STATUS".

I'm not questioning that it will not "run" on any build log. Why would it not?
I can also give an mp4 video to less and less will also "run". That doesn't
mean that less is going to do anything meaningful. So yes, I expect blhc to
"run" on any build log. It will just not be useful to do so in many (most?)
cases.

Lintian and piuparts can (and should) be run after any release build.

Autopkgtests are not defined for all packages but I'd argue that they *should*
which is why I added functionality to make running it easier: as an incentive
for more people to add autopkgtests to their packages.

But giving blhc the same treatment has no such advantages. You also didn't
discuss at all why one should then not add 20 more flags for all the other
compilers if we now have a special checker for gcc.

> On Mon, Nov 14, 2016 at 03:12:03PM +0800, Paul Wise wrote:
> > I don't think they should be part of it at all but anyway...
> I find it extremely useful to be able to type 'dgit sbuild' right
> before an upload and have all these sanity checks be run.

pabs' argument here is, that having the checkers be part of sbuild is a layer
violation. Instead of letting sbuild do everything, there should be a wrapper
around sbuild which does the package build and runs checkers or other stuff as
requested. I'd not argue against that, but right now, I don't see any useful
sbuild "wrapper" around and thus the lintian, autopkgtest and piuparts checkers
will remain in sbuild.

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20161114/f0f7f0dd/attachment.sig>