Bug#657390: lintian: Please make build-arch and build-indep required targets

[Guillem Jover <guillem@debian.org>]

Hi!

On Tue, 2013-01-22 at 23:16:06 +0000, Roger Leigh wrote:
> On Thu, Jan 10, 2013 at 11:46:46AM +0100, Niels Thykier wrote:
> > Things have changed a bit since we talked about this last year.
> > 
> > This number is now about 3700, which is still a bit much.  In the
> > interest of not getting a lot of mail from people aggrevated by their
> > package being auto-rejected, I still feel the tags should remain split
> > for now (until that number drops a bit more and Wheezy has been released).
> > 
> > I am open to bumping the severity of the recommended-target tag
> > (possibly including a rename) to make the tag more visible and hopefully
> > increasing the adoption rate of this tag (well, the post-freeze adoption
> > rate).
> 
> Ccing the dpkg maintainers, since the lintian checks will be
> coupled to changes in the tools, and it's really down to them
> when this happens.

Well, I'm really not comfortable deciding unilaterally on a flag day
when thousands of packages will start FTBFS, for something that will
affect so many people. I think this should be discussed and agreed
with the project at large.

In any case my opinion on this is that yes, getting rid of the
autodetection hack before jessie is out, would be ideal, but if that
cannot happen, then oh well, this has taken a looong time, having to
wait a bit longer should not be the end of the world.

I think the less painful way to achieve that would be by a staged
increase of the enforcing level of those targets, where changing dpkg
to require them should be the last stage when really few packages
still do not provide it, because otherwise mass rebuilds, binNMUs and
similar become very painful.

The first stage could be to wait a bit after testing thaws to see the
progress; after a bit, change/rename the tag to an error w/o autoreject.
Wait and see how it progresses, and after a bit more (several months)
change it to autoreject, but not for binNMUs if that's possible? to
avoid disrupting the release process. And then only a small tail
should remain which could be handled by a MBF etc. After or during
this last stage dpkg could be switched.

Thanks,
Guillem