Re: Bug#657390: lintian: Please make build-arch and build-indep required targets
On 2013-01-23 04:46, Guillem Jover wrote:
> Hi!
>
Hi,
Restarting this as Wheezy has been out for a while.
> 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).
>>
> [...]
>
> 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.
>
At March 1st, we had 3630 packages missing at least one recommended
target according to Lintian. Yesterday, the number was 3122. Both
numbers include source packages in sid and in experimental, so it may be
slightly inflated[1].
The change translates to about 85 packages a month are being
"fixed"[2], but our graph suggests that somewhere between May and July
the rate increased[3]. Indeed, for the last month, a total of 96 (~3 a
day) were "fixed".
If the current rate is sustained, we are looking at ~3 years for this
problem to fix itself. Even if we assume 10% of these to only affect
experimental (see [1]) and all fixes affect sid, we are still look at
~2.5 years.
> [...]
>
> Thanks,
> Guillem
>
>
On 2013-01-24 23:13, Roger Leigh wrote:
> On Wed, Jan 23, 2013 at 04:46:06AM +0100, Guillem Jover wrote:
> [...]
>> 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.
>
> I think this all makes a good deal of sense. It's certainly
> logistically impractical to "force" the issue by changing dpkg until
> the vast majority of packages are converted, so we certainly need to
> encourage adoption by other means and do this as the final step.
>
So, the question is now - do we want to scale up the enforcement level,
and, if so, to what? As mentioned earlier, I am willing to increase the
severity of the tag (provided it does not become an auto-reject overnight).
> As for when build-arch and build-indep were introduced, I'll be happy
> to do a set of whole-archive rebuilds to obtain concrete numbers once
> wheezy is released, and onward from that as needed, if I can get
> access to the hardware to do this.
I would be interested in seeing the results from this kind of build-testing.
~Niels
[1] That is, if a package is available in sid and experimental, it can
count for up to two packages missing a recommended target. From memory,
during the freeze about 10% of all packages in sid were also available
in experimental.
[2] I write "fixed" because removing the package from experimental can
cause this number to drop as well despite the sid version still being
affected.
[3]
http://lintian.debian.org/tags/debian-rules-missing-recommended-target.html
Reply to: